Настройка производительности сервера PostgreSQL
Есть сервер:
CPU: Intel(R) Xeon(TM) CPU 3.60GHz
real memory = 2147352576 (2047 MB)
В настоящий момент живёт с почти умолчательным конфигом:
max_connections = 40
shared_buffers = 28MB
max_fsm_pages = 179200
effective_cache_size = 512MB # По умолчанию было 128 и совсем грустно.
log_destination = 'syslog'
silent_mode = on
autovacuum = on
datestyle = 'iso, mdy'
lc_messages = 'C'
lc_monetary = 'C'
lc_numeric = 'C'
lc_time = 'C'
Для случая Мускула с MyISAM на моей задаче размер базы стабилизировался в районе 4.2 гига (для Postrges'а предполагаю что-нибудь в 1.5-2 раза бОльшее).
Производительность (при использовании шаблона my-huge.cnf) на наличном железе была достаточной.
С Postgers'ом при размере базы 2,5G - заметные тормоза. И заметно более интенсивный обмен данными с диском.
Главной причиной, по которой пришлось искать альтернативы Мускулу - табличная блокировка (запросы на зачистку базы выполняются достаточно долго).
Поэтому категорически желательно (и насколько я понял отсутствие блокировки таблиц при выполнении запросов INSERT/DELETE.
Разжёванный конфиг видел, но как/куда крутить реально используемый - пока не представляю.
- Для комментирования войдите или зарегистрируйтесь
Сам сейчас
Сам сейчас кручу запихивание как можно большего из БД в оперативку
Прокурил вот что: http://www.revsys.com/writings/postgresql-performance.html
Пожалуйста, не описывайте своё железо в подписи
=
Знакомая ссылка :)
Насколько я её курил - подходящего к моей задачем там не то, чтобы много и явно не компактно :(
--
Live free or die
В общем, как у
В общем, как у себя наковыряю что-нибудь для себя, так тут и отпишусь. Или в Яббер стукнись, если хочешь
Пожалуйста, не описывайте своё железо в подписи
shared_buffers = 28MB Не
shared_buffers = 28MB
Не маловато ли? В жеваном конфиге писано что потолок это 1/3 озу. А помогает при больших количествах соединений (это не про вас, бо 40), больших таблицах, "комплексных" запросах...
А вообще имхо, игрушки все это. Для сервера базы данных 80% выигрыша в производительности даeт правильная индексация таблиц и жесткая оптимизация запросов. К примеру замена or на and в условиях отбора (where) делает из 15 минутного запроса пятисекундный.
.
В конфиге про этот параметр написано (если без купюр):
# - Memory - shared_buffers = 28MB # min 128kB or max_connections*16kB # (change requires restart)Менять пробовал. При изменении этого значения (даже банально до 32MB) сервер не стартует. Странно как-то... Надо будет разобраться.
Ты не забывай про поправку на область применимость "ИМХО" :)
И про то, что от конфигурации сервера таки зависит, и немало.
Но оптимизация самой базы - это основной путь в ситуации, когда база первична.
В ситуации же, когда база вторична (и нет особого желания лезть в неё ручками), например как у меня (SQL-backend для спам-фильтра) очень хочется обойтись оптимизацией сервера.
--
Live free or die
не забыли?
autovacuum = on # enable autovacuum subprocess? # 'on' requires stats_start_collector # and stats_row_level to also be onлгн
Это ядрёный параметр меньше, чем shared_buffers. Подробнее тут:
http://www.postgresql.org/docs/current/static/kernel-resources.html
Это ещё что, я тут поднял shared_buffers до 128 Мб (всего у меня 1,5 Гб), так только замедлилось. Поднял до 512 Мб — ещё больше замедлилось (-%Е
Пожалуйста, не описывайте своё железо в подписи
.
Thanks.
Только вот что: Мускул-то [почти совершенно] адекватно работал с тем же ядром.
Так что, думается мне, крутить надо что-то другое...
Вывод: крутить надо что-то другое.
Там есть ещё такой интересный параметр, как work_mem (Specifies the amount of memory to be used by internal sort operations and hash tables before switching to temporary disk files. The value is specified in kilobytes, and defaults to 1024 kilobytes (1 MB). Note that for a complex query, several sort or hash operations might be running in parallel; each one will be allowed to use as much memory as this value specifies before it starts to put data into temporary files. Also, several running sessions could be doing such operations concurrently. So the total memory used could be many times the value of work_mem; it is necessary to keep this fact in mind when choosing the value. Sort operations are used for ORDER BY, DISTINCT, and merge joins. Hash tables are used in hash joins, hash-based aggregation, and hash-based processing of IN subqueries. ), попробуй покрутить его.
В имеющемся у меня примере конфига есть ещё пара буферов (значения не заданы):
temp_buffers ( Sets the maximum number of temporary buffers used by each database session. These are session-local buffers used only for access to temporary tables. The default is eight megabytes (8MB). The setting can be changed within individual sessions, but only up until the first use of temporary tables within a session; subsequent attempts to change the value will have no effect on that session.
A session will allocate temporary buffers as needed up to the limit given by temp_buffers. The cost of setting a large value in sessions that do not actually need a lot of temporary buffers is only a buffer descriptor, or about 64 bytes, per increment in temp_buffers. However if a buffer is actually used an additional 8192 bytes will be consumed for it (or in general, BLCKSZ bytes). )
wal_buffers (Number of disk-page buffers allocated in shared memory for WAL data. The default is 8. The setting need only be large enough to hold the amount of WAL data generated by one typical transaction.)
--
Live free or die
Quote: Только вот
Ну вот не факт. Схемы работы у Мускуля и Постгрескуля с памятью могут сильно различаться.
Я для начала попробую понять, за каким дьяволом она шуршит диском в два раза больше, если дать ей 512 метров оперативки (-:Е
Пожалуйста, не описывайте своё железо в подписи
Пока суть да
Пока суть да дело, первым шагом я решил реализовать возможность разнесения по разным физическим дискам собственно базы данных и журнала транзакций (не забыть посмотреть статистику: кто из них больше грузит диск):
PostgreSQL 8.0 Performance Checklist
--
Live free or die
И как
И как результат?
Мне не особо поможет, к сожалению, у меня с чтением проблема
Пожалуйста, не описывайте своё железо в подписи
:(
Вряд ли смогу ответить на этот вопрос.
Ибо разнесение журнала и собственно базы по разным дискам запланировано в качестве одной из вспомогательных мер.
Если преимущественно чтение, то почему не Мускул?
--
Live free or die
Ы
Потому что далеко не только чтение. Это сейчас, на конкретном этапе разработке мы застряли на чтении. Пишет-то как раз хорошо, процессор с обработкой запросов не справляется, а в БД-то всё пишется.
Да и InnoDB всё равно понадобится, в MyISAM нету связей между таблицами типа REFERENCE, если я ничего не путаю, а она тоже не скоростная
Пожалуйста, не описывайте своё железо в подписи
По предварительным оценкам
По предварительным оценкам, пиковая интенсивность обмена данными с жёстким диском уменьшилась в среднем где-то на треть (в тяжёлых случаях - может четверть, в оптимистичном раскладе может превышать половину).
И по процессору процентов 20...
Только всё это - полумеры, как изначально и предполагалось... :(
--
Live free or die
Я тут два часа
Я тут два часа посидел на их IRC-канале... Много чего наслушался, но пока не выносил мысли никакой определённой. Но народ старался помочь, рекомендую и тебе попробовать.
Пожалуйста, не описывайте своё железо в подписи
.
Адресочек не подскажешь?
Сие можно было предсказать заранее.
Потому и не стремлюсь пробовать этот вариант
Я тут по ходу выяснил, что у меня затык скорее - в ограничении числа подключений к базе.
Поэтому сейчас я свалился на уровень ОС и системно-специфических фичей.
Разгребусь (попутно попробовав формализовать принцип определения необходимого числа подключений к базе), определюсь с достаточностью - и ждите меня снова :)
--
Live free or die
ß
irc://irc.freenode.net#postgresql , как ни странно (-:Е
А вот, кстати, я понял, что они до меня донести пытались
У меня вся БД не влезала в оперативку, а запрос требовал последовательного сканирования всей таблицы. То есть в кэше лежал хвост таблицы с прошлого запроса, а надо было начинать с самого начала каждый раз. Поэтому всё опять упиралось в скорость винта.
Ну это дело проправимое. max_connections там, pgpool наконец
Пожалуйста, не описывайте своё железо в подписи
ну...
не всегда, в особо запущенных случаях нужно увеличивать колочество портов в системе и прочие штуки.
:(
Почему? ИМХО вопрос в ресурсоёмкости и степени исправления.
Но дело скорее поправимое.
Да, есть такое. :(
Ну, на сколько необходимо увеличивать эти значения с учётом прочих сервисов - никто кроме меня не скажет.
Но есть ещё такой добрый вопрос: а чем чревато увеличение этих значений?
--
Live free or die
плохая привычка
ты расковырял предложение посередине, я имел в виду что если к базе потребуется 70 000 одновременных подключений то внутренние утилиты базы скорее всего не помогут.
я когда-то читал вот это:
http://www.tigase.org/en/linux-settings-guide
Мониторинг узких мест
По ходу разборок сформулировался следующий вопрос:
Где стоит ждать (искать) затыка и собственно алгоритм определения во что упираешься в данном конкретном примере на текущей итерации?
--
Live free or die
Ну как минимум
Ну как минимум есть EXPLAIN ANALYZE. Из того, что сразу приходит в голову.
Пожалуйста, не описывайте своё железо в подписи
Это - к
Это - к SQL-запросам.
Я же (по крайней мере на данном этапе) оптимизирую производительность сервера...
--
Live free or die
Это покажет, на
Это покажет, на чём затыкается конкретный запрос, что вполне может дать ключ к проблеме медленнодействия сервера (-:Е
Пожалуйста, не описывайте своё железо в подписи