У меня есть сервер с 4 ГБ ОЗУ и PostgreSQL 9.0.3 на Centos 5. Я использую pgbench
и pgbench-tools
для измерения производительности с помощью двух pgbench-tools
запросы: select
и tpc-b
.
С настройками по умолчанию postgresql.conf
и используя запрос выбора, я получаю следующие результаты:
Масштаб: 1, 10, 100, 1000.
Транзакций в секунду: 10000, 8800, 7500, 100.
(количество записей таблицы в масштабе * 100000)
Я увеличил вариант shared_buffer
до 256 МБ (ранее было 32 МБ), и я получаю следующие результаты:
Масштаб: 1, 10, 100, 1000.
Транзакций в секунду: 10000, 8000, 3200, 30
Почему производительность такая низкая по сравнению с первым тестом когда шкала 100 и более во втором тесте? Единственное, что я сделал - увеличил память.
Единственное, что постоянно делает pgbench медленнее при увеличении shared_buffers, - это опция отладки, называемая проверкой утверждения. Если вы сделаете это в psql:
show debug_assertions;
И он включен, ваша сборка имеет эту проблему, и результаты, которые вы видите, ожидаемы. Вам нужна новая установка, которая не включена для отладки утверждений, чтобы избавиться от нее.
В противном случае, если бы вы не делали все это более одного раза, я бы не был так уверен, что причиной здесь было изменение shared_buffers. В качестве одного примера, если автоочистка запускается в точке, где работает ваша крупномасштабная база данных, это замедлит результаты тестирования. Контрольная точка, запускаемая одновременно с началом теста, тоже будет. Отключите автоочистку, чтобы исключить его из теста, и включите log_checkpoints, чтобы проверить, не мешает ли он.
Третья возможность, и я почти уверен, что вы в какой-то степени страдаете, заключается в том, что что-то, перемещающееся на диске, может вызвать 50% замедление результатов. Диски примерно в два раза быстрее на ранних этапах, чем на более поздних, и, если вы запускаете pgbench несколько раз, данные будут перемещаться в более медленные части по мере продвижения. В конечном итоге я перестраиваю всю файловую систему, чтобы получить повторяемые результаты, - это единственный способ убедиться, что вы начинаете с одной и той же точки на диске. Это не влияет на результаты в меньших масштабах, потому что все они умещаются в ОЗУ.
Когда я вижу изменение производительности после касания параметра конфигурации, я всегда пробую исходную конфигурацию еще раз, чтобы убедиться, что это была причина. Я часто удивляюсь, обнаруживая, что тест становится медленнее каждый раз, когда вы его запускаете, и эта разница в скорости расположения на диске является одним из источников этой проблемы.