поделюсь немного своей статистикой:
сервер postgresql 9.2, ssd (MO0200EBTJU) под flashcache, запущено в сентябре 2012г., суточная нагрузка колеблется от 40K до 120К запросов к базе в минуту.
Usage remaining: 99.95%
Power On Hours: 4770
Estimated Life Remaining based on workload to date: 397301 days
Позволю немного сарказма)))
В нашей стране эта диаграмма не работает… многие чиновники имеют хорошие связи, хитры на выдумки, не гнушаются обмана и не утруждают себя упорным трудом, однако в категорию бедных их не отнесешь.
про поле svctm в оф.мане написано «Warning! Do not trust this field any more. This field will be removed in a future sysstat version.»
и еще -t и 10 это два отдельных параметра
При переезде менялись только shared_buffers work_mem maintenance_work_mem effective_cache_size
pgbouncer не используется.
попробовал сейчас оценить выйгрыш при сравнении картины «до и после» на слейве, но увы забикс уже порезал подробные графики в графики трендов. но если смотреть на большой период, то какого-то колосального выйгрыша практически незаметно))
> Утилита весьма хитро запрятана, так что «home page» у неё просто нет, только гит-репозиторий.
# eix sys-block/fio |grep Homepage
Homepage: brick.kernel.dk/snaps/
на домашнюю страничку не тянет, зато есть все версии fio, blktrace и других утилиток
С точки зрения администратора, все прошло гладко (не считая того сервиса основанного на pgq и схем переносимых руками).
От разработчиков я не слышал, о каких-то проблемах которые вылезли в коде. Про прирост конкретных цифр не назову =) могу лишь сказать о том, что когда сранивали выполнение топовых запросов, от разработчиков были слышны возгласы «О… ничтяк...»
Как то так)))
Вобще надо построить отчеты фуина и сравнить с тем что было. Но как всегда, некогда((
база — 49Gb
отчеты фуина строятся по 5-6 часов и строим их только тогда, когда приспичит))) (при max_duration_statement = 0)
статистика по master'у до переезда:
Number of unique normalized queries: 6,590
Number of queries: 46,166,027
Total query duration: 125h30m24s
First query: 2012-09-11 00:00:01
Last query: 2012-09-12 00:00:02
Query peak: 2,074 queries/s at 2012-09-11 01:14:04
статистика по slave'у до переезда:
Number of unique normalized queries: 1,276
Number of queries: 60,776,531
Total query duration: 30h02m10s
First query: 2012-09-11 00:00:01
Last query: 2012-09-12 00:00:02
Query peak: 1,754 queries/s at 2012-09-11 13:05:32
о 20k запросах в секунду даже думать не приходится))))
я врядли смогу что-то посоветовать с вашими масштабами,… мне наоборот даже интереснее поближе посмотреть на вашу инфраструктуру )))
flashcache-тома настраиваем в режиме writearound поэтому потеря диска, в данном случе не страшна. В случае выхода из строя мы заменим его на новый. Полученный выйгрыш производительности гораздо больше чем затраты на диск.
По поводу переноса таблиц в отдельные tablespace думали как-то давно, но по каким-то причинам решили этого не делать, уже не помню почему.
сервер postgresql 9.2, ssd (MO0200EBTJU) под flashcache, запущено в сентябре 2012г., суточная нагрузка колеблется от 40K до 120К запросов к базе в минуту.
Usage remaining: 99.95%
Power On Hours: 4770
Estimated Life Remaining based on workload to date: 397301 days
собственно пока все очень неплохо
класс!) на лезвии ножа, админ тру гентушник
насчет бедных, имхо у любого бедного человека один и тот же менталитет который как раз подпадает под вышеуказанную диаграмму
В нашей стране эта диаграмма не работает… многие чиновники имеют хорошие связи, хитры на выдумки, не гнушаются обмана и не утруждают себя упорным трудом, однако в категорию бедных их не отнесешь.
и еще -t и 10 это два отдельных параметра
postgresql.conf старой машины уже канул в неизвестность
после 2х Xeon 5650 (выделено 24 ядра), 48GB RAM, HDD SAS+SSD (flashcache)
postgresql.conf
shared_buffers = 12000MB
work_mem = 64MB
maintenance_work_mem = 512MB
checkpoint_segments = 32
checkpoint_timeout = 10min
checkpoint_completion_target = 0.6
random_page_cost = 2.0
effective_cache_size = 35000MB
default_statistics_target = 250
При переезде менялись только shared_buffers work_mem maintenance_work_mem effective_cache_size
pgbouncer не используется.
попробовал сейчас оценить выйгрыш при сравнении картины «до и после» на слейве, но увы забикс уже порезал подробные графики в графики трендов. но если смотреть на большой период, то какого-то колосального выйгрыша практически незаметно))
# eix sys-block/fio |grep Homepage
Homepage: brick.kernel.dk/snaps/
на домашнюю страничку не тянет, зато есть все версии fio, blktrace и других утилиток
От разработчиков я не слышал, о каких-то проблемах которые вылезли в коде. Про прирост конкретных цифр не назову =) могу лишь сказать о том, что когда сранивали выполнение топовых запросов, от разработчиков были слышны возгласы «О… ничтяк...»
Как то так)))
Вобще надо построить отчеты фуина и сравнить с тем что было. Но как всегда, некогда((
отчеты фуина строятся по 5-6 часов и строим их только тогда, когда приспичит))) (при max_duration_statement = 0)
статистика по master'у до переезда:
Number of unique normalized queries: 6,590
Number of queries: 46,166,027
Total query duration: 125h30m24s
First query: 2012-09-11 00:00:01
Last query: 2012-09-12 00:00:02
Query peak: 2,074 queries/s at 2012-09-11 01:14:04
статистика по slave'у до переезда:
Number of unique normalized queries: 1,276
Number of queries: 60,776,531
Total query duration: 30h02m10s
First query: 2012-09-11 00:00:01
Last query: 2012-09-12 00:00:02
Query peak: 1,754 queries/s at 2012-09-11 13:05:32
о 20k запросах в секунду даже думать не приходится))))
я врядли смогу что-то посоветовать с вашими масштабами,… мне наоборот даже интереснее поближе посмотреть на вашу инфраструктуру )))
По поводу переноса таблиц в отдельные tablespace думали как-то давно, но по каким-то причинам решили этого не делать, уже не помню почему.