необходимо составить критерии загруженности СУБД сервера.
от чего лучше плясать

LA ? (условные попугаи которые толком ничего не говорят, но если LA большое понятно что все плохо :) )
Disk I/O ? (диском могут дрыгать и другие процессы, а если СУБД в отдельном openvz контейнере, то могут дрыгать и другие VPS's)
free memory ? (тоже не совсем то)

нужен совет как определить создавать еще базы на хосте или всё...

еще проблема в том что запросы бывают быстрые и медленные и повлиять на это невозможно (разработчики совершенно отдельные люди контролю не поддающиеся :) )

можно только вот что это даст?
крайнее значение 500 1000 2000 или 4000 блоков с секунду ?
в этом вся и проблема что железки разные и одна при I/O 1000 клеит ласты а та что поновее норм работает серваков около 10 и их количество будет естессно увеличиватся.

Теперь про OVZ в свое время мы наелись ситуациями когда какой то наш альтернативно одаренный коллега запускал какой то говноскрипт и ел всю память, естессно ограничение по памяти и по процессам помогает, НО если это сервак СУБД ???

есть статистические запросы бекэнд от корорых может отъесть 1-2ГБ и это нормально, а если таких запросов 3 или 4 ? т.е. по памяти процессы ограничить нормально не получается...

еще есть тупорые запросы идиотов, которые сами не понимают что делают (а их идиотов у нас около 50 ти) и ядро в попытках освободить память начинает стрелять во все стороны и частенько натыкается на совершенно не нужный процесс sshd :)



при использовании OVZ ssh на хост машине не умрет никогда, при самом плохом стечении обстоятельств либо через vzctl enter <id> либо vzctl restart <id> и все нет проблем,
тем более у нас в конторе новая мода пошла (наконец то) нагрузочное тестирование и обсуждение сколько новому проекту нужно ресурсом и часто проекты по 2-3 частично переписываются (раньше бы просто запустили бы в комерцию а потом бы ели мозг "а почему оно ложится при нагрузке, давайте еще ")

про логгирование запросов это понятно, только с нашим количеством сервисов и запросов в этих логах можно закопатся, при чем теже статистические запросы не быстрые и это нормально...

ЗЫ спасибо за ответ, а какие у вас были проблемы с OVZ ?



izкажется, в openvz возможно получить iostat/vmstat по каждой ноде отдельно
можно включить лог запросов и посмотреть их производительность -- это финальный тест загруженности сервера

плюс нужно четко представлять себе, что вы хотите получить от постгреса в виртуальной машине, это очень неудачная конфигурация по моему опыту

0) Спасибо за ответ.

1) Логи это выход, как то совсем упустил это из виду, вы протоколируете все запросы или с временем выполнения от 1 000 мс например ?

2) как шутили у нас в коллективе "я не буду ставить ядро 2.6 пока субминор будет менее 24-х "
как говорится в каждой шутке есть доля шутки :)

альтернативно одаренных ограничить не получится тк, время разработчиков расписано на год вперед и около 50 чел активно генерят новые проекты... поток сознания имеет невероятные объемы... да и что б переломать сущ схему (с базой работают от пользователя у которого права на select,insert,update,delete) нужно много времени...

про trusted роли почитаю к сож про это пока не слышал.

3) посмотрел на кривульки в забиксе и согласился с вами больше наверное плясать не от чего....
по пикам понятен предел возможностей IO


iz1. Анализ логов. Вы натравливаете на логи утилитку pgFouine и она сама выдает вам аггрегатную статистику, не нужно закапываться в лог-файлах. В отчете вы увидите, например, сколько всего времени в сутки сервер провел, выполняя запросы -- и станет понятно, рассчитан он на такое или нет.

2. Проблемы с OpenVZ у меня были когда в production система изредка убивала бакенды PostgreSQL с непонятными сигналами и при этом не мотались никакие каунтеры по превышению лимитов -- было абсолютно невозможно понять, какой именно лимит превышен. Админ не знал, что делать. На форуме опенвз на мои вопросы все скромно молчали и поэтому я был вынужден экспериментировать на продакшн-машине, как мог. Очень неприятная ситуация. Пропало после радикального повышения основных лимитов. А то, что каунтеры не мотались вроде было сочтено багом и в новых опенвз-ядрах этого якобы не должно быть. Ну и вообще, гуру не советуют распихивать постгресы по виртуальным машинам. Драка за ресурсы всегда отжирает очень много этих самых ресурсов.

Если же вам нужно ограничить ресурсы для алтернативно-одаренных коллег в PostgreSQL, есть некоторые возможности это сделать. Например, разделяйте надежных и ненадежных пользователей, которым выставляйте жесткий statement_timeout и per-user настройки работы постгреса с памятью, например. Аналитические запросы пускайте же через trusted-роли. Ну что-то подобное, я бы не стал отказываться от такого варианта без его рассмотрения и анализа.

Нагрузочное тестирование нужно проводить не на девелоперских машинах, либо на них, когда они совсем не заняты, иначе у вас получатся смещенные оценки, что в виртуальной машине, что в реальной. Так что это не может служить поводом использования OpenVZ и даже, я бы сказал, тестирование в OpenVZ систем, которые будут работать не в виртуальных машинах, скорее всего является порочной практикой.

И вообще OpenVZ -- это удобная игрушка для админов, когда у них не хватает физического железа, не больше. В реальной жизни нужно использовать виртуализацию *очень* осторожно, потому что не все в ней гладко идеологически.

3. IO. Это вы сами должны знать, сколько блоков в секунду тянет ваша железка, а вернее, даже конкретнее -- дисковая подсистема. Или вы хотите запустить программку, которая вам скажет: "ваш сервер загружен на 83%, пожалуйста, подумайте об апгрейде в ближайшие 22 дня"? Так что иостат + знание возможностей железа + голова = отличная возможность осознать загрузку сервера.