Всем привет. Подскажите пожалуйста, очищаю буферный кеш, чтобы померить скорость

запросов на холодную. Делаю сначала очистку в Ubuntu и перезагружаю postgresql. Но при выполнении запроса с explain вижу все равно shared hit меньше, но вижу. В чем может быть причина?

> Подскажите пожалуйста, очищаю буферный кеш, Как Вы это делаете, каким способом? > чтобы померить скорость запросов на холодную. А зачем Вы это делаете, если не секрет? Вы же измеряете производительность СУБД ровно в тех условиях, в которых она ни в коем случае не должна работать. > В чем может быть причина? Либо в том, что не очищаете, либо в том, что данный запрос просматривает некоторые блоки многократно (это довольно часто бывает). Соответственно, в первый раз это shared read, в последующие — shared hit.

1. echo 3 > /proc/sys/vm/drop_caches и перезагружаю постгрес 2. Ранее была проблема с получением данных, там был биг дата так сказать. В старой структуре запроса на холодную он делался 1 и более минуты. А потом 17 секунд. Сейчас запрос переписали и вроде все быстро, отдача 50 мс, но оч хотелось понять не будет ли проблем с первым запуском. Так как ранее еще была ситуация, столкнулся с ситуацией что там оказался мертвый жесткий диск, и запрос выполнялся 5 мс, а первый раз минуту. Тогда посоветовали проверить жесткий и это оказалось правда. Хочется перестраховаться, так как пользователь к своим данным обращается 1 раз в два дня, но если пришел, то начинает их гонять. И не хотелось иметь запрос, когда он пришел и ждве минуту. 3. То есть в одном запрос если он просматривает один и тот же блок два раза, то он попадает в shared hit?

> 1. echo 3 > /proc/sys/vm/drop_caches и перезагружаю постгрес Да, это правильно. > но оч хотелось понять не будет ли проблем с первым запуском. Всегда могут быть, к сожалению. Т.е. обычно ориентируются на работу СУБД в нормальном режиме, потому что обычно она продолжается гораздо дольше, чем заполнение кешей при перезапусках / перезагрузках (т.е. под эти ситуации в ущерб нормальной работе смысла оптимизировать обычно нет). Т.о. то, что первое (после перезагрузки, в смысле) выполнение запроса гораздо дольше последующих — нормально. Но если Вас всё-таки интересует время "на холодную" — да, результатам такого способа можно верить (но в идеале Вы должны сбросить кеши — выполнить единственный запрос — опять сбросить кеши...). > И не хотелось иметь запрос, когда он пришел и ждве минуту. СУБД общего назначения — не real time, именно гарантий на время выполнения добиться от них не удастся. Можно искусственно "подогреть" кеш, конечно (см. https://www.postgresql.org/docs/current/pgprewarm.html )... но PostgreSQL его всё равно вытеснит, если эти данные будут просто "простаивать" в RAM. > 3. То есть в одном запрос если он просматривает один и тот же блок два раза, то он попадает в shared hit? Да, почти наверняка (и даже если этот блок параллельно прочитал любой другой запрос, в другой сессии). Т.е. то, что читается, кешируется в shared buffers, пока там есть место (они же для этого и нужны, собственно). Вытеснение обычно начинается тогда, когда места там уже нет.

Да, субд будет использоваться по назначению. Как говорил ранее хотелось понимать допустимую разницу при первом запросе и считывания блоков и последующих нормальных запросах так сказать. Интересно почему когда просматриваю кеш в Ubuntu он был 800 мб у примеру, а становится после сброса 230 мб. Это какая то не сбрасываемая часть?

Спасибо за такие подробные ответы

спасибо огромное за развернутые ответы