Я пытаюсь исправить проблему с высокой загрузкой процессора PostgreSQL. Мы используем PostgreSQL 8.0.9, и когда наше веб-приложение JEE (в JBoss) используется в определенных условиях увеличения нагрузки, наверху отображается медленное увеличение процессов для PostgreSQL. Когда возникает проблема, имеется примерно 12-15 процессов PostgreSQL, каждый из которых показывает SELECT справа от информации о процессе, и примерно 6-7% использования ЦП каждый, а затем приложение сильно замедляется.
Версия JBoss: JBoss (MX MicroKernel) 4.0.3
Операционная система: CentOS Linux 5.5
Ядро и процессор: Linux 2.6.18-194.26.1.el5 на x86_64
Информация о процессоре: 2 x Intel (R) Xeon (R) CPU E5420 @ 2,50 ГГц, 8 ядер
В настоящее время мы думаем добавить к этому больше оборудования. Если мы сделаем это, что будет лучшим вариантом, например, вариант A ниже или вариант B?
Вариант A: 4 процессора AMD Opteron ™ 6100 Series по 12 ядер каждый
Вариант B: 4 процессора Intel® Xeon® серии 7500, каждый по 8 ядер
Правильно ли предположить, что CentOS Linux 5.5 с PostgreSQL 8.0.9 будет пропорционально масштабироваться с добавлением такого количества процессоров и ядер (например, 4 процессора с 12 ядрами каждый)? Есть ли что-то еще, что я должен рассмотреть с точки зрения увеличения количества оборудования?
На вопрос невозможно ответить, мы понятия не имеем, что происходит. Вы говорите о 12-15 связях, это почти ничего. Но при выполнении очень сложных запросов или использовании плохой схемы базы данных, отсутствия индексов и т. Д. Использование процессора может возрасти в любой момент.
Версия 8.0.9 представляет собой серьезную проблему, 8.0 является EOL по состоянию на октябрь 2010 года, а последнее исправление - версия 8.0.26 (исправления ошибок за 4 года после 8.0.9). Вы должны хотя бы обновить эту версию, чтобы исправить многие ошибки в 8.0.
Начните регистрировать запросы, используйте EXPLAIN, чтобы увидеть план запроса, взгляните на VACUUM, и вам также может понадобиться REINDEX. На данный момент ваше оборудование выглядит нормально, сначала вам нужно найти источник проблем.
Подумайте о том, чтобы нанять базу данных PostgreSQL на пару дней.
Когда возникает проблема, имеется примерно 12-15 процессов PostgreSQL, каждый из которых показывает SELECT справа от информации о процессе, и примерно 6-7% использования ЦП каждый, а затем приложение сильно замедляется.
12x6 = 72%, поэтому даже в самой низкой точке процессоры довольно загружены. Добавьте сюда все остальное, и станет совершенно ясно, почему вы работаете на пределе. (Предполагается, что вы смотрите на процессоры как на совокупность; когда вы смотрите на время процесса в topты нажимаешь 1 ключ, чтобы увидеть все время процессора по отдельности, или просто глядя на число, которое он представляет, что представляет собой все процессоры вместе взятые?)
В настоящее время мы думаем добавить к этому больше оборудования. Если мы сделаем это, что будет лучшим вариантом, например, вариант A ниже или вариант B?
Вариант A: 4 процессора AMD Opteron ™ 6100 Series, каждый по 12 ядер
Вариант B: 4 процессора Intel® Xeon® серии 7500, каждый по 8 ядер
Больше ядер. PostgreSQL будет использовать модель «процесс на ядро», поэтому чем больше, тем лучше. Я бы посмотрел, может быть, на 2 процессора AMD по 12 штук на 24 ядра в сумме, а затем со временем купил бы оставшиеся 2 процессора, чтобы вы могли рассчитать их бюджет.
Правильно ли предположить, что CentOS Linux 5.5 с PostgreSQL 8.0.9 будет пропорционально масштабироваться с добавлением такого количества процессоров и ядер (например, 4 процессора с 12 ядрами каждый)?
Да. Я могу ошибаться, но я считаю, что старые компиляторы ядра использовали фиксированное число в файле заголовка C для определения максимального числа процессоров, которые нужно искать, которое обычно имело верхнюю границу 32 во время компиляции. Если бы у вас была «большая» машина, вы бы просто увеличили число до большего и перекомпилировали. Не совсем уверен, но я думаю, что они удалили эту константу в серии 2.6, так что все должно быть в порядке.
Есть ли что-то еще, что я должен рассмотреть с точки зрения увеличения количества оборудования?
Возможно, вы захотите еще немного взглянуть на настройку программного обеспечения, прежде чем бросать на него оборудование (или настроить его и все же получить новое оборудование).
Если это оператор SELECT, есть ли шанс, что вы можете его зарегистрировать, а затем использовать EXPLAIN, чтобы узнать, где он проводит свое время? Используйте PgAdmin для запуска и настройки запроса вручную, пока вы не сможете немного уменьшить время выполнения. Если оператор SELECT является программным, вы все равно можете оценить влияние использования нового индекса.
Сколько памяти вы выделили для PostgreSQL? Сколько в расчете на процесс? Сколько выделено разделяемой памяти? Все это может отрицательно повлиять на работу базы данных.
Существуют ли какие-либо другие процессы или службы, которые можно отключить (чтобы освободить память) или переназначить (чтобы снизить потребление ЦП)?
Я думаю, тебе пригодится книга PostgreSQL 9.0 Высокая производительность. Он доступен в формате PDF (мгновенная загрузка), а также в формате мертвого дерева.
Мы только что перестроили нашу базу данных, следуя советам из этой книги. Наша новая база данных превосходит старую, и нам не пришлось тратить на это кучу денег. Есть главы, которые посвящены каждому из ваших вопросов. Есть ответы, но еще лучше, есть также методы (как вы измеряете свое оборудование, чтобы узнать, насколько оно быстро?)
Я не эксперт по Postgresql, но я расскажу вам, что я узнал об оборудовании и Postgresql. Ваш пробег может отличаться.
В общем, для баз данных, с которыми я имел опыт работы, важнее, чем количество и скорость процессоров:
Вы получаете пропускную способность ввода-вывода с RAID. RAID10 подходит для большинства данных Postgresql. Чем больше дисков, тем выше производительность. Если можете, поставьте xlog на отдельное устройство. Это может быть RAID1. Использование аппаратной карты RAID с кэш-памятью с резервным питанием от батареи обеспечит максимальную производительность.
Если вы демонстрируете высокую загрузку ЦП, это может быть связано с медленными запросами. Я бы предложил включить функции медленного ведения журнала запросов в postmaster.conf и проверка запросов, которые занимают больше времени, чем следовало бы.
Также существует вероятность того, что вы привязаны к вводу-выводу, поскольку медленные диски могут легко вызвать начало резервного копирования запросов. Я бы предложил установить htop и проверка того, какой процент времени ожидания процессора приходится на iowait.
Кроме того, я настоятельно рекомендую перейти на последнюю версию. Начиная с версии 8.0, производительность значительно улучшилась, а текущая стабильная версия (9.0.x на момент написания) предлагает больше информации, когда EXPLAIN VERBOSE ANALYZEзапросы.
Вообще говоря (при прочих равных условиях) PostgreSQL очень хорошо масштабируется по мере добавления ядер (каждое дополнительное ядро добавляет примерно 96% прирост производительности (из возможных 100% теоретического прироста производительности на каждое дополнительное ядро)).
Однако у меня изначально интуитивное ощущение, что ваши диски не успевают.
Недавно я столкнулся с аналогичными проблемами в небольшой базе данных (7 таблиц, 30 МБ) с запросами, имеющими много соединений. Машина представляет собой виртуальную машину с 2 ГБ оперативной памяти и всегда использует менее 160 МБ. Это сработало очень быстро, пока мы не добавили около 1 миллиона новых данных. Затем сервер (8.4.5) начал загружать 100% ЦП в течение от 5 секунд до 30 минут с теми же запросами, которые были меньше секунды.
Нам удалось решить проблему обновлением сервера. Тесты с 8.4.9 и 8.4.12 не показали плохого поведения (но с 8.4.8).