Как стать автором
Обновить

Комментарии 4

Эх. Это все найти можно и так. А вот с точки зрения оптимизации запросов порекомендуйте лучше, как оптимизировать работу PG с кешем. Есть редко читающие данные клиенты, есть активный фоновый скрипт обновления этих данных. Когда работает фоновый скрипт, он «вышибает» из кеша данные. И когда клиент инициирует какой-то запрос, то первый запрос выполняется десятки секунд, второй — около 1,5 секунд, третий и последующие — 0,32-0,45 секунды. Как только наступает пауза минут на 5 хотя бы — опять все повторяется.

Естественно, хорошо видно, как при последовательных SELECT сокращается число read и растет shared hits.

Как бы объяснить PG, что мне важнее в кеше данные для SELECT, а не UPDATE?
В статье речь идет о дисковом кэше. Он настраивается на уровне системы, а не простгреса, к сожалению, Вы не сможете контролировать его содержимое. Поэтому, лучше оптимизировать запрос. Возможно, облегчить его — убрать всякие условия и джоины, а логику обработки данных вынести в сам скрипт.
Уже так и сделал. Только SELECT. Даже сортировку делаю в скрипте, джойнов и групировок нет. Все равно не помогает. А кеш дисковой системы также забивается INSERT'ами. :( В этом смысле как раз большая засада Postgres. Пока я не разобрался, что причина в «заполнении кеша» я долго не мог понять, что не работает. Приложение работает долго, а EXPLAIN потом показывает огромную скорость. А просто EXPLAIN — это уже второй-третий вызов.

Что интересно, MySQL в аналогичных условиях ведет себя намного корректней и быстрее именно по первому запросу.
В системный кэш попадают все файлы, которые использует система на текущий момент. Если дисковые операции очень интенсивны, то старые данные (не обязательно файлы таблиц постгреса) оттуда будут быстро вытесняться. EXPLAIN запроса, должен показать какая операция выполнятеся медленно. Если у Вас большой объем данных, для которых он использует простой перебор, то возможно имеет смысл создать индекс для этой таблицы, и/или попробовать задать более жесткие условия на выборку.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории