Comments 13
отличная статья, спасибо
А используя flashcache вы не боитесь, что SSD «протрётся» от активных операций по записи? Выгоднее ли это переноса части редко-записываемых таблиц в tablespace на SSD-диске?
А используя flashcache вы не боитесь, что SSD «протрётся» от активных операций по записи? Выгоднее ли это переноса части редко-записываемых таблиц в tablespace на SSD-диске?
flashcache-тома настраиваем в режиме writearound поэтому потеря диска, в данном случе не страшна. В случае выхода из строя мы заменим его на новый. Полученный выйгрыш производительности гораздо больше чем затраты на диск.
По поводу переноса таблиц в отдельные tablespace думали как-то давно, но по каким-то причинам решили этого не делать, уже не помню почему.
По поводу переноса таблиц в отдельные tablespace думали как-то давно, но по каким-то причинам решили этого не делать, уже не помню почему.
Если можно на некоторое время (порядка нескольких часов) отключить апдейты данных (а на слейвах все равно возможны только r/o запросы), то есть более простая схема:
— поднимаем на будущем мастере 9.2 временно 9.0
— реплицируем на него данные с текущего мастера 9.0 (пока что работа кластера никак не изменилась по отношению к скриптам).
— отключаем апдейт данных (слейвы продолжают работать)
— останавливаем новый мастер и делаем бинарный апгрейд данных до 9.2, запускаем как мастер (до этого был слейвом по отношению к 9.0 мастеру)
— на слейвах поднимаем паралельно по инстансу 9.2 с новыми апгрейжеными данными, настроенными реплицироваться с нового мастера.
— проверяем что репликация работает и новый паралельный кластер на 9.2 в порядке
— переключаем r/o скрипты на слейвах на 9.2 инстансы
— переключаем скрипты апдейта данных на 9.2 мастер, запускаем
— проверяем все
P.S. схему в бою пока не проверял, у самого такая проблема, пока обдумываю как получше её решить
— поднимаем на будущем мастере 9.2 временно 9.0
— реплицируем на него данные с текущего мастера 9.0 (пока что работа кластера никак не изменилась по отношению к скриптам).
— отключаем апдейт данных (слейвы продолжают работать)
— останавливаем новый мастер и делаем бинарный апгрейд данных до 9.2, запускаем как мастер (до этого был слейвом по отношению к 9.0 мастеру)
— на слейвах поднимаем паралельно по инстансу 9.2 с новыми апгрейжеными данными, настроенными реплицироваться с нового мастера.
— проверяем что репликация работает и новый паралельный кластер на 9.2 в порядке
— переключаем r/o скрипты на слейвах на 9.2 инстансы
— переключаем скрипты апдейта данных на 9.2 мастер, запускаем
— проверяем все
P.S. схему в бою пока не проверял, у самого такая проблема, пока обдумываю как получше её решить
UFO just landed and posted this here
база — 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 запросах в секунду даже думать не приходится))))
я врядли смогу что-то посоветовать с вашими масштабами,… мне наоборот даже интереснее поближе посмотреть на вашу инфраструктуру )))
отчеты фуина строятся по 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 запросах в секунду даже думать не приходится))))
я врядли смогу что-то посоветовать с вашими масштабами,… мне наоборот даже интереснее поближе посмотреть на вашу инфраструктуру )))
Если не секрет, что «отвалилось» из при переходе с 9.0 на 9.2 (не верю, что всё идеально)? Существен ли прирост скорости при выполнении запросов?
С точки зрения администратора, все прошло гладко (не считая того сервиса основанного на pgq и схем переносимых руками).
От разработчиков я не слышал, о каких-то проблемах которые вылезли в коде. Про прирост конкретных цифр не назову =) могу лишь сказать о том, что когда сранивали выполнение топовых запросов, от разработчиков были слышны возгласы «О… ничтяк...»
Как то так)))
Вобще надо построить отчеты фуина и сравнить с тем что было. Но как всегда, некогда((
От разработчиков я не слышал, о каких-то проблемах которые вылезли в коде. Про прирост конкретных цифр не назову =) могу лишь сказать о том, что когда сранивали выполнение топовых запросов, от разработчиков были слышны возгласы «О… ничтяк...»
Как то так)))
Вобще надо построить отчеты фуина и сравнить с тем что было. Но как всегда, некогда((
Прирост конечно просто колоссальный судя по графикам… Но хочется как то оценить саму разницу между 9.0 и 9.2 в плане производительности, ведь разработчики заявляют что 9.2 стал в 2 раза быстрее, а кое в чём и в 5 раз…
Приведите пожалуйста характеристики серверов до переезда(оператива, диски, процы) и не плохо бы конфиги postgres(сколько shared memory, сколько под работу) и pgbouncer(сколько пул) чтобы примерно уложить в голове какая часть приплюснутой производительности появилась от flashcache, какая от postgres 9.2…
Приведите пожалуйста характеристики серверов до переезда(оператива, диски, процы) и не плохо бы конфиги postgres(сколько shared memory, сколько под работу) и pgbouncer(сколько пул) чтобы примерно уложить в голове какая часть приплюснутой производительности появилась от flashcache, какая от postgres 9.2…
до. 2x Xeon 5650 (выделено 16 ядра), 16GB RAM, HDD SAS
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 не используется.
попробовал сейчас оценить выйгрыш при сравнении картины «до и после» на слейве, но увы забикс уже порезал подробные графики в графики трендов. но если смотреть на большой период, то какого-то колосального выйгрыша практически незаметно))
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 не используется.
попробовал сейчас оценить выйгрыш при сравнении картины «до и после» на слейве, но увы забикс уже порезал подробные графики в графики трендов. но если смотреть на большой период, то какого-то колосального выйгрыша практически незаметно))
Вот теперь видно откуда такой прирост.
shared memory было 4Гб, стало аж 12Гб. + дисковый кэш увеличился до ~30-32Гб против 8Гб до переезда…
если поставите pgbouncer и ограничите пул до ~20-24 то сможете ещё shared memory увелить смело до 40Гб… Обычно pgbouncer используют для снижения нагрузки на винт, но у Вас сейчас нагрузка ушла в процы. пул в 20-24 уменьшит кол-во переключений контектов у процессов postgres и недаст засвописться: 24*64Мб + (иногда 512Мб) + мелочи всякие = ~3Гб. поэтому 35Гб под shared можно, а это наверно ~50% базы в памяти.
shared memory было 4Гб, стало аж 12Гб. + дисковый кэш увеличился до ~30-32Гб против 8Гб до переезда…
если поставите pgbouncer и ограничите пул до ~20-24 то сможете ещё shared memory увелить смело до 40Гб… Обычно pgbouncer используют для снижения нагрузки на винт, но у Вас сейчас нагрузка ушла в процы. пул в 20-24 уменьшит кол-во переключений контектов у процессов postgres и недаст засвописться: 24*64Мб + (иногда 512Мб) + мелочи всякие = ~3Гб. поэтому 35Гб под shared можно, а это наверно ~50% базы в памяти.
И ещё вопрос. А у Вас на мастере и слейве в shared memory одинаковые таблички и индексы или На мастере одна группа таблиц, а на слейве другая? Это к вопросу эффективности использования оперативной памяти на мастере и слэйве…
Sign up to leave a comment.
Переезд с PostgreSQL 9.0 на 9.2 под нагрузкой