Производительность PostgreSQL на EC2 / EBS - PullRequest
8 голосов
/ 10 июня 2010

Что дает лучшую производительность для запуска PostgreSQL на EC2? EBS в RAID? PGData on / mnt?

Есть ли у вас какие-либо предпочтения или опыт? Основным «плюсом» для запуска PostgreSQL на EBS является переключение с одного экземпляра на другой. Может ли это быть причиной медленнее, чем использование раздела / mnt?

PS: я использую PostgreSQL 8.4 с данными / размером около 50G, экземпляром Amazon EC2 xlarge (64).

1 Ответ

7 голосов
/ 10 июня 2010

Здесь есть некоторая связанная информация.Главный вывод - это сообщение от Брайана Мерфи:

На Amazon уже 1,5 года очень занятая база данных OLTP Postgres 170+ ГБ на Amazon.Я не могу сказать, что я "счастлив", но я заставил это работать и все еще предпочитаю, чтобы он бегал по центру города в 3 часа ночи, когда что-то идет не так.

Есть две основные вещис осторожностью относитесь к:

1) Физический ввод / вывод не очень хорош, таким образом, как эта первая система использовала RAID0.

Давайте будем здесь понятны, физический ввод / вывод находится нараз ужасно .:)

Если у вас большая база данных, тома EBS станут настоящим узким местом.Нашей основной базе данных требуется 8 томов EBS на диске RAID, и мы используем slony для разгрузки запросов на две подчиненные машины, и она по-прежнему не в состоянии поддерживать.

Мы не могли бы запустить эту базу данных на одной EBSтом.

Я также рекомендую использовать RAID10, а не RAID0.EBS тома не работают.Чаще всего отдельные тома будут испытывать очень длительные периоды низкой производительности.Чем больше дисков у вас в рейде, тем больше вы сгладите.Однако были случаи, когда нам приходилось заменять неэффективно работающий том на новый и перестраивать RAID, чтобы восстановить скорость.Вы не можете сделать это с массивом RAID0.

2) Надежность EBS ужасна по стандартам базы данных;Я прокомментировал это уже в http://archives.postgresql.org/pgsql-general/2009-06/msg00762.php Конечным результатом является то, что вы должны быть осторожны с резервным копированием данных, при этом рекомендуется постоянное потоковое резервное копирование с помощью доставки WAL.Я бы не стал развертывать эту среду в ситуации, когда потеря минуты или двух транзакций в случае сбоя в EC2 / EBS была бы неприемлемой, потому что это нечто более вероятное, чем на большинстве аппаратных средств баз данных.

Согласовано.У нас есть три запасных части WAL.Один из них направляет наши файлы WAL на один том EBS, который мы используем для резервного копирования снимков в худшем случае.Две другие являются точными копиями нашей первичной базы данных (одна в центре обработки данных на западном побережье, а другая в центре обработки данных на восточном побережье), которую мы используем для восстановления после отказа.

Если нам когда-либо понадобится наихудший случай-При восстановлении сценария из одного из наших снимков EBS мы не работаем в течение шести часов, потому что нам придется передавать данные из нашего снимка EBS обратно в массив EBS raid.170 ГБ при 20 Мбит / с (если вам повезет) занимает много времени.Для того чтобы один из этих снимков стал «пригодным для использования» после того, как мы создадим из него диск, потребуется от 30 до 60 минут, а затем нам все еще придется задействовать базу данных и мучительно долго ждать, пока горячие данные вернутся в память.

За последние 1,5 года нам пришлось дважды переходить на одну из наших запчастей.Не смешно.Оба раза происходили из-за сбоя экземпляра.

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

Брайан

...