Postgresql грузит процессор на 100
I'm using an open source (RHEL 6.2) based machine running SIEM software. When I run the top command, I see postgres and postmaster both with 96% CPU usage. Is there a way to pin-point or see what causing these service to stack up?
"RHCE 6.2"? Do you mean "RHEL 6.2" ? I assume postgress is postgres and you've just copied it by hand.
5 Answers 5
You can match a specific Postgres backend ID to a system process ID using the pg_stat_activity system table.
SELECT pid, datname, usename, query FROM pg_stat_activity; can be a good starting point.
Once you know what queries are running you can investigate further ( EXPLAIN / EXPLAIN ANALYZE ; check locks, etc.)
is this the exact query, I'm not much familiar with db as im the sec guy working on siem, your select statement, do i have to feed it pid from top command ?
@asadz no, it was truncated (fixed now) -- If you have specific PIDs and want to see what they're running you can isolate them with a WHERE clause, but if you don't have a huge number of PIDs it's just as easy to search through the full output. The Postgres manual has additional detail on what you can get out of pg_stat_activity , as well as the other statistics-collector tables (which can help you if your problem isn't a user query).
Thanks for the clue, recently I met similar issue and figured out the reason by using SELECT * FROM pg_stat_activity;
I was having the same issue. The postgresql is setup on AWS RDS and it was having 100% cpu utilisation even after increasing the instance. I debugged with the method shown here and one of the method worked for me.
I checked for the query running for the longest time and came to know that certain queries was stuck and was running since more than 3-4 hours. To check since how much time the query is running, run the following command:
If this is more than an hour, than this is the issue. Kill the long running connection and limit the max age of the connection from application side.
If this is really the postmaster using all that CPU, then you likely have lock contention issues, probably due to very high max_connections . Consider lowering max_connections and using a connection pooler if this is the case.
Otherwise: Details, please. Full output of top -b -n 1 for a start.
this make sense ; since the siem is used by analyst to query lot of data back and forth; is there a way i can check on the lock status; or conditions attributed to it; ?
First, pg_stat_activity (from the other answers) is good advice — and I think sometimes it's not enough? It shows the current activity only, but what if there are many many quick queries, which don't last long enough for them to look interesting in pg_stat_activity ? However when there're many many of them, they might still cause high CPU usage?
Then you can use pg_stat_statements :
pg_stat_statements records queries that are run against your database, strips out a number of variables from them, and then saves data about the query, such as how long it took, as well as what happened to underlying reads/writes.
Here I use it to find out why my own CPU usage is unexpectedly high:
Did you notice something, above? — There top queries are quick: 0.009 and 0.004 seconds. But they get called many many times.
Взяв за основу статью Петра Зайцева об узких местах в производительности MySQL (MySQL Performance Bottlenecks), я хочу немного рассказать о PostgreSQL.
В наши дни для работы с PostgreSQL часто используются ORM-фреймворки. Обычно они работают хорошо, но со временем нагрузка увеличивается и возникает необходимость тюнить сервер базы данных. Каким бы надежным ни был PostgreSQL, но и он может тормозить при увеличении трафика.
Есть много способов устранения узких мест в производительности, но в этой статье мы обратим внимание на следующее:
- Параметры сервера
- Управление подключениями
- Настройка автоочистки (autovacuum)
- Дополнительная настройка автоочистки
- Раздувание таблиц (bloat)
- «Горячие точки» в данных
- Сервера приложений
- Репликация
- Серверное окружение
О «категориях» и «потенциальном влиянии»
«Сложность» говорит о том насколько просто реализовать предлагаемое решение. А «потенциальное влияние» дает представление о степени улучшений в производительности системы. Однако в силу возраста системы, ее типа, технического долга и т.п. точное описание сложности и влияния может быть проблематичным. В конце концов, в сложных ситуациях окончательный выбор всегда за вами.
- Сложность
- Низкая
- Средняя
- Высокая
- Низкая-средняя-высокая
Настройка автоочистки (autovacuum)
Сложность: средняя.
Потенциальное влияние: низкое-среднее.Управление параллельным доступом посредством многоверсионности (Multi-Version Concurrency Control) — один из основополагающих принципов, делающих PostgreSQL таким популярным решением среди СУБД. Однако одним из неприятных моментов является то, что для каждой измененной или удаленной записи создаются неиспользуемые копии, от которых в конечном итоге надо избавляться. Неправильно настроенный процесс автоочистки (autovacuum) может снижать производительность. При этом чем сервер загруженнее, тем сильнее проявляется проблема.
Для управления демоном автоочистки используются следующие параметры:
- Параметр autovacuum_max_workers. При наличии большого количества огромных таблиц стоит увеличить количество одновременно работающих процессов автоочистки (по умолчанию три). В идеале должен быть один рабочий процесс на один процессор, но не больше количества процессоров. Слишком большое количество может увеличить нагрузку на процессор. Обычно берется значение между двумя этими числами. Это баланс между максимальной эффективностью автоочистки и общей производительностью системы.
- Параметр maintenance_work_mem. Чем больше значение, тем эффективнее процесс очистки. Имейте в виду, что есть закон убывающей отдачи. Слишком большое значение в лучшем случае станет пустой тратой оперативной памяти, а в худшем может исчерпать всю доступную память.
- Параметр autovacuum_freeze_max_age уменьшает вероятность TXID WRAPAROUND. Чем значение больше, тем реже он запускается, что снижает нагрузку на систему. Но, как и со всеми параметрами автоочистки, упомянутыми выше, есть нюанс. Если сделать задержку слишком большой, то и вы рискуете исчерпать txid, что приведет к принудительному завершению работы сервера в целях защиты целостности данных. Для определения правильного значения необходимо сопоставлять самый большой/старый txid с процессом автоочистки используя pg_stat_activity на предмет WRAPAROUND.
Аналогично вычислению work_mem, это значение можно посчитать арифметически или выполнить бенчмарки для получения оптимальных значений.
Дополнительная настройка автоочистки
Сложность: высокая.
Потенциальное влияние: высокое.Этот метод, из-за его сложности, следует использовать только когда производительность системы уже на грани физических пределов хоста и это действительно стало проблемой.
Runtime-параметры автоочистки настраиваются в postgresql.conf . К сожалению, нет единого универсального решения, которое будет работать в любой высоконагруженной системе.
Параметры хранения для таблиц. Часто в базе данных значительная часть нагрузки ложится только на несколько таблиц. Настройка индивидуальных параметров автоочистки для таблицы — отличный способ не прибегать к ручному запуску VACUUM, который может существенно влиять на систему.
Настроить таблицы можно с помощью команды:
Серверное окружение
И последнее, но не менее важное — это простое увеличение мощности хоста. Давайте рассмотрим, на что влияет каждый из ресурсов в плане производительности PostgreSQL:
Есть сервер с 5-тым Centos-ом с установленным PostgreSQL 8.1. В top постоянно висят несколько процессов postmaster, которые в сумме загружают процессора на ~40%. Причем база не большая, PG обслуживает только локальных клиентов, который тоже не много. В логи смотрел, ничего криминального.
С кривыми таблицами и кривыми запросами можно сделать так, что табличка с одним полем и одной записью будет тормозить
Это похоже на предложение лечить подземный стук. Если ты смотрел логи и все хорошо, видимо все работает как нужно?
tps смотрел какой? Лог медленных запросов смотрел? Какой iowait? И самое главное, тебе мешает именно цифра 40%, или может какие то объективные есть показатели, медленное выполнение запросов например?
Да, я понимаю, что, возможно, недостаточно точно описал проблему. Это потому что я практически незнаком с PG и поначалу я даже не знал где логи-то искать. Завтра попробую найти этот лог медленных запросов и погуглить что такое tps.
А что до 40%, то я считаю, что ничего не делающая СУБД не должна так сильно нагружать проц.
СУБД в данном случае виднее делает она что то или нет. Пусть хоть на 100% загружает процессоры, если результат (скорость выполнения запросов) хороший. Посмотри vmstat, iostat, конфиги сервера. Если ты с чем то «практически незнаком», то не стоит чего то крутить без необходимости, ведь запросы не тормозят.
>не стоит чего то крутить без необходимости, ведь запросы не тормозят.
10 запросов в минуту не тормозят и в SQLite :) В данном случае тормозит весь сервер, на котором работать становится невозможно.
Причину так и не нашел. select * from pg_stat_activity; показывает порядка 5 подключений. LA сервера колышится от 2.5 до 3.5, при этом свап практически не используется. Хм.
и где vmstat, iostat?
У меня возникали те же вопросы
С тем же постгресом и тем же центосом.
(это, типа, стихи такие) :)Возникали они при переезде с 8.0.4, кажется, на более новую - давненько было.
Смотрите postgresql.conf на предмет:
shared_buffers
work_mem
maintenance_work_mem
checkpoint_segments
max_fsm_pages
vacuum_cost_delay
effective_cache_size
random_page_costВообще, гугль, как обычно, знает ответ на «оптимизация настройки postgresql». См. 1-ю и 2-ю ссылки.
>и где vmstat, iostat?
iostat не установлен и ставить не стал.
ну тут iowait 0, диск ничего не нагружает, видимо в самом деле все криво. «top c» покажет чего делает постгресс в простейшем случае
> select * from pg_stat_activity; показывает порядка 5 подключений.
Всем привет. Поставил Postgresql для 1С. Запустил туда большую конфу с большой базой. До этого все крутилось на оффтопSQL. При попытке даже 1 клиента что-то делать, работает очень медленно. В htop вижу, что висит процесс postgresql с SELECT и жрет 100% одного ядра. Этого явно не достаточно. Почему так происходит? И почему postgres не использует все ядра? Спасибо.
1 запрос == 1 поток. Если ты запустишь 10 запросов, будет 10 потоков и 10 ядер.
а как 1 SELECT будет занимать больше 1 ядра?
А как он делает это на МСsql?
Смотря на чем висит процесс если на ожидании I/O то какая разница сколько у тебя ядер.
а вот чудесный вопрос. я даже запросил бы пруф с 1 жирненьким селектом, который распараллелится.
Если ядро в 100% уходит, очевидно что его производительности не достаточно для этого селекта.
а я и не спорю. как параллелить то? если на 100 процентов грузит, то либо ждать, либо руки из задницы пересаживать и переписывать запрос.
Индексные ключи выставлены по таблицам?
Постгрес тюнил на использование памяти?
Ну немного. Сейчас занимаюсь конкретно. Из-за не настроенной памяти могут быть траблы описанные мной в начале поста?
ммммм. а кто-нибудь ваще переписывал БД под MT ? :)
А постгря с патчами от 1С?
Сделай этот же селект, только руками, будет разница ?
Еще как вариант тупит винт, посмотри может идет ребилд массива или есть битые сектора, пройдись викторией.Версия PostgreSQL (1C-патченая?)? Версия платформы? Разрядность? Что за конфигурация и какой объем БД? Какое железо? Тест Гилёва на сервере проводили?
exorcist ★ ( 09.06.15 22:44:12 )
Последнее исправление: exorcist 09.06.15 22:45:34 (всего исправлений: 1)Вот еще можете попробовать потюнить сам PostgreSQL. Но этот скрипт у меня рассчитан на сервер, где крутиться один PostgreSQL, сам кластер 1С на соседнем работает.
Нужно профайлером посмотреть что за запросы бегут на сервер. Хорошая книжка по тюнингу слона тут.
Нужно профайлером посмотреть что за запросы бегут на сервер
абсолютно бесполезно, увидев хоть раз запрос 1С сразу хочется их развидеть.
LOG: duration: 15998.049 ms statement: DELETE FROM _CRgActP657 WHERE EXISTS( SELECT 1 FROM (SELECT 1 AS SDBL_DUMMY) SDBL_DUAL INNER JOIN (SELECT T4._RecorderTRef AS RecorderTRef, T4._RecorderRRef AS RecorderRRef, T4._LineNo AS LineNo_ FROM _CRgActP657 T4 INNER JOIN tt2967 T5 ON T4._RecorderTRef = T5._RecorderTRef AND T4._RecorderRRef = T5._RecorderRRef AND T4._LineNo = T5._LineNo LIMIT 100000) T3 ON _CRgActP657._RecorderTRef = T3.RecorderTRef AND _CRgActP657._RecorderRRef = T3.RecorderRRef AND _CRgActP657._LineNo = T3.LineNo_ WHERE _CRgActP657._RecorderTRef = T3.RecorderTRef AND _CRgActP657._RecorderRRef = T3.RecorderRRef AND _CRgActP657._LineNo = T3.LineNo_)
и это еще не самый страшный. причем как заметно выполнялся 16сек, после установки серверного ключа выполняется намного быстрее.
для проверки скорости можно запускать тест гилева, как уже много раз писалось на всяких 1С ресурсах: 1С гоняет большие объемы не оптимизированных данных в памяти, так что берите процессор ++3.5Гц + память DDR4-2100 и выше и 40 попугаев вам будет обеспечено.
anonymous2 ★★★★★ ( 10.06.15 12:27:17 )
Последнее исправление: anonymous2 10.06.15 12:27:40 (всего исправлений: 1)С дефолтной установкой у меня, насколько помню, тоже еле шевелилось.
postgreSQL с сайта 1С, 8.3.6, x64, Конфигурация почти самопал, размер .dt файла 110 Гб, Железо - 2x6 ядер Xeon (какой точно не скажу, но не старый), все стоит на 10 аппаратном RAID.
На хосте только pg или всё скопом с сервером 1С?
Все скопом. Но проц в простое, память свободна, диск в простое. По этому мануалу произвел настройку. Разница есть, но не большая. Все равно все очень медленно. Запользовал pgtune - так же, разницы почти никакой. При любом тыке в интерфейс С-ки в процессах висит SELECT и жрет одно ядро в 100%
При любом тыке в интерфейс С-ки в процессах висит SELECT и жрет одно ядро в 100%
Блжад. Неужели сложно сделать explain analyze?
У тебя сервер с ключём?
Сколько процессов?Ключ по сети раздает другая машина. Процессов 1с приложения? Я один сейчас сижу, по разному от 2 до ~20
Гилев показывает 12.9 G1C тест в процессе.
Ключ по сети раздает другая машина.
Ключ серверный может быть установлен только локально.
В сервер со всем этим добром HASP воткнут?
Программных лицензий на него раньше не было.Тогда там у тебя ОДИН рабочй процесс.
А учитывая что 8.3 не даёт регулировать рабочие потоки, ещё и ОДИН рабочий поток.
Втыкай ключ.Если будет ключ, будет несколько рабочих процессов, соотв будет несколько процессов которые будут инициировать несколько одновременных запросов в БД? Где можно почитать о том, что Вы говорите? Про процесс и поток?
Кстати сервер 1С приложения стоит в LXC контейнере. Нормально ключ работает, не в курсе?
Я не знаю как туда USB прокидывать, на XEN'е 8.2 сервер работал нормально.
Если будет ключ, будет несколько рабочих процессов, соотв будет несколько процессов которые будут инициировать несколько одновременных запросов в БД?
Вестимо, да.
Не стоит забывать, что 1С пилят, в первую очередь под M$SQL, с грехом-пополам переводя это на pg, и полуая в результате откровенную наркоманию в запросах.Где можно почитать о том, что Вы говорите? Про процесс и поток?
Я читал кучу мелких источников, в том числе гилёва, мисту и вот тут кастовал вопросы.
Думаю, поиск в любимом se по запросу «сервер 1с процесс поток linux» поможет сориентироваться.Ну про наркоманию не спорю, но живых примеров удачных внедрений уже очень много.
если у тебя конфа не дефолтная, там запросы могут быть сильно на T-SQL завязаны.
Торговля но переделанная на 90%. T-SQL вроде не использовали.
Была похожая проблема. Возможно проц не на полную работает. Попробуй CPU frequency scaling на performance переключить. В убунте пакет cpufrequtils.
У меня проблемы с моим LAMP-сервером. В последнее время все стало очень медленно, хотя количество посетителей на моих сайтах сильно не изменилось. Когда я запускаю top команду, она говорит, что процесс MySQL занял 150-200% процессорного времени. Как это возможно, я всегда думал, что 100% это максимум?
Я использую серверную версию Ubuntu 9.04 с 1,5 ГБ оперативной памяти.
Что может быть причиной этой проблемы? Могу ли я внести изменения в мой, my.cnf чтобы предотвратить зависание сервера?
- Увеличьте ключевой буфер (у вас сейчас 64 МБ, но суммарные индексы составляют 116 МБ, поэтому установите не менее 128 МБ). Должно помочь немедленно.
- Запустите mysqloptimize и mysqlrepair на ваших столах
- Увеличьте кеш таблиц / уменьшите общее количество таблиц, чтобы увеличить частоту обращений к кешам таблиц. Возможно, у вас есть неиспользованные или старые таблицы, которые можно удалить.
Другие рекомендуемые варианты конфигурации:
- log_slow_queries = /var/log/mysql/mysql-slow.log
- long_query_time = 4
- лог-запросы, не использующие индексы-
Проверьте файл журнала через некоторое время.
У вас есть процессор с несколькими ядрами или несколько процессоров. Если у вас два ядра и процесс использует 100% обоих ядер, он будет отображаться как 200% сверху.
Аналогично, это, вероятно, работает как задумано - с вашей конфигурацией все в порядке. Если вы испытываете частые зависания, из того, что вы опубликовали, вы можете захотеть добавить правильные индексы в свои таблицы (или оптимизировать свои запросы).
Запустите, top -H чтобы увидеть все запущенные потоки, а не только общий процесс. Кроме того, если вы нажмете 1 клавишу в верхней части, он покажет вам использование процессора для отдельных процессоров / ядер.
Спасибо, это действительно помогло мне - много лет использовал топ и не знал, что у него есть такая способность. Я обнаружил, что существует один «вечный» поток mysql, который все время потребляет 60% ЦП, в то время как потоки запросов приходят и уходят поверх этого. Теперь, чтобы узнать, что на самом деле делает эта тема .
Mysql имеет несколько процессов (потоков), работающих независимо, например, один отвечает за запись данных из памяти на диск. При наличии нескольких ядер в ЦП (и / или нескольких ЦП) работает более одного потока, и поэтому он может работать более чем на 100% одного ядра - на упрощенном уровне, возможно, работает 75% каждого из двух ядер , давая 150%.
Я заметил проблему, не связанную с процессором. Если вы используете apache и MySQL на одном сервере, вы можете достичь плохих условий ( ОЗУ ), когда ваша активность apache возрастет.
MySQLTunner сообщает вам, что, используя 200 доступных подключений (ваш максимальный параметр подключения), вы будете заполнять оперативную память. Допустим, у вас ограничен процесс Apache до 150, и вам наверняка не хватит оперативной памяти, когда MySQL и apache попытаются использовать 150 соединений (поскольку Apache также является хорошим потребителем ОЗУ).
Так что речь идет об оперативной памяти, и вы, возможно, еще не нажали :-) Верхние команды показывают только 15 процессов Apache (но вы загружаетесь в среднем 3/6/16, так что это означает, что шторм был 15 минут назад и сейчас в оставляя).
Что касается проблемы с процессором, чтобы дополнить хороший ответ shakalandy , это может быть из-за одного запроса. Это может быть огромная таблица, выполнение множества заданий по переиндексации, использование большого количества временных файлов, отсутствие индекса (удаление?) И т. Д. Единственный способ обнаружить его - активировать журнал медленных запросов (может быть, с высоким порогом, как 8s). Затем используйте инструмент mysqlsla для анализа этого медленного журнала запросов и выполните некоторые объяснения по идентифицированным запросам.
Раздувание таблиц (bloat)
Сложность: низкая.
Потенциальное влияние: среднее-высокое.Со временем производительность системы может ухудшаться из-за неправильных политик очистки, вследствие чрезмерного раздувания (bloat) таблиц. Так что даже настройка демона автоочистки и ручной запуск VACUUM не решает проблему. В этих случаях на помощь приходит расширение pg_repack.
С помощью расширения pg_repack можно перестроить и реорганизовать таблицы и индексы в условиях продакшена
Управление подключениями
Сложность: низкая.
Потенциальное влияние: низкое-среднее-высокоеВысокая нагрузка обычно связана с увеличением сессий клиентов в единицу времени. Слишком большое их количество может блокировать процессы, вызывать задержки или даже приводить к ошибкам.
Простое решение — увеличить максимальное количество одновременных подключений:
Но более эффективный подход — пул соединений. Существует множество решений, но наиболее популярное — pgbouncer. PgBouncer может управлять соединениями, используя один из трёх режимов:
- Пул сеансов (session pooling). Наиболее корректный подход. При подключении клиента ему выдается соединение и остается за ним, пока он не отключится. Когда клиент отключается, подключение возвращается в пул. Это метод по умолчанию.
- Пул транзакций (transaction pooling). Подключение назначается клиенту только на время транзакции. Когда PgBouncer замечает, что транзакция завершена, подключение возвращается в пул.
- Пул операторов (statement pooling). Наиболее агрессивный метод. Подключение к серверу будет возвращаться в пул сразу после завершения запроса. Транзакции с несколькими операторами в этом режиме запрещены, так как они будут прерываться.
Репликация
Сложность: низкая.
Потенциальное влияние: высокое.Синхронная и асинхронная репликация. Последние версии postgres поддерживают логическую и потоковую репликацию как в синхронном, так и в асинхронном режимах. Хотя по умолчанию используется асинхронный режим репликации, но необходимо учитывать последствия использования синхронной репликации, особенно в сетях с существенной задержкой.
Параметры сервера
Сложность: низкая.
Потенциальное влияние: высокое.Еще не так давно были времена, когда актуальные версии postgres могли работать на i386. С тех пор настройки по умолчанию были изменены, но они по-прежнему сконфигурированы на использование наименьшего количества ресурсов.
Эти параметры изменить очень просто и обычно они настраиваются при первоначальной установке. Неправильные значения этих параметров могут привести к высокой загрузке процессора и ввода-вывода:
- Параметр effective_cache_size ~ от 50 до 75%
- Параметр shared_buffers ~ 1/4 – 1/3 объема оперативной памяти
- Параметр work_mem ~ 10МБ
Вычисление значения shared_buffers — интересная головоломка. На нее можно смотреть с двух сторон: если у вас небольшая база данных, то можно установить значение shared_buffers достаточно большим, чтобы вся база данных поместилась в оперативной памяти. С другой стороны, можно настроить загрузку в память только часто используемых таблиц и индексов (вспоминайте правило 80/20). Раньше рекомендовалось устанавливать значение в 1/3 объема оперативной памяти, но со временем, так как объемы памяти росли, оно было уменьшено до 1/4. Если памяти выделено мало, то будет увеличиваться ввод-вывод и нагрузка на процессор. О слишком большом выделении памяти будет свидетельствовать выход на плато загрузки процессора и ввода-вывода.
Еще один фактор, который следует учитывать — это кэш ОС. При достаточном объеме оперативной памяти Linux будет кэшировать таблицы и индексы в памяти и, в зависимости от настроек, может заставить PostgreSQL поверить в то, что он читает данные с диска, а не из оперативной памяти. Одна и та же страница находится и в буфере postgres и в кэше ОС, и это одна из причин не делать shared_buffers очень большим. С помощью расширения pg_buffercache можно посмотреть использование кэша в реальном времени.
Параметр work_mem задает объем памяти, используемый для операций сортировки. Установка слишком низкого значения гарантирует плохую производительность, так как сортировка будет выполняться с использованием временных файлов на диске. С другой стороны, хотя установка большого значения и не влияет на производительность, но при большом количестве подключений есть риск нехватки оперативной памяти. Проанализировав память, используемую всеми запросами и сеансами, можно посчитать необходимое значение.
Используя EXPLAIN ANALYZE можно увидеть, как выполняются операции сортировки, и, изменяя значение для сеанса, определить момент, когда начинается слив на диск.
Можно также использовать бенчмарки системы.
«Горячие точки» в данных
Сложность: высокая.
Потенциальное влияние: низкое-среднее-высокое.Как и в случае с MySQL, избавление PostgreSQL от «горячих точек» зависит от ваших потоков данных и может даже повлечь за собой изменение архитектуры системы.
В первую очередь следует обращать внимание на следующее:
- Индексы. Убедитесь, что для столбцов, по которым осуществляется поиск есть индексы. Можно использовать системные каталоги и представления для мониторинга и проверки, что запросы используют индексы. Для анализа производительности запросов используйте расширения pg_stat_statement и pgbadger.
- Heap Only Tuples (HOT). Индексов может быть и слишком много. Снизить потенциальное раздувание и уменьшить размер таблицы можно, удалив неиспользуемые индексы.
- Секционирование таблиц. Ничто так не влияет на производительность, как огромная таблица, размер которой в несколько раз превышает средний размер других таблиц. Разбивка большой таблицы на более мелкие секции поможет повысить производительность запросов, например, при запросе данных, секционированных по дате. И так как таблица может обрабатываться только одним процессом автоочистки, то разбивка его на множество меньших таблиц позволяет более чем одному процессу автоочистки выполнять автоматическое удаление. Еще одно преимущество секционирования в том, что удаление большого количества строк намного эффективнее и быстрее, чем из единой огромной таблицы.
- Параллельные запросы. Появились в последних версиях postgres. Теперь для выполнения одного запроса может использоваться несколько процессоров, тогда как раньше запрос обрабатывался только одним.
- Денормализация. Можно повысить производительность, объединив столбцы из нескольких таблиц в одну таблицу. Повышение производительности достигается за счет увеличения избыточности данных. Тщательно обдумайте этот вариант, прежде чем его использовать!
Сервера приложений
Сложность: низкая.
Потенциальное влияние: высокое.Избегайте запуска приложений (PHP, Java и Python) и postgres на одном хосте. Относитесь внимательно к приложениям на этих языках, так как они могут потреблять большие объемы оперативной памяти, особенно сборщик мусора, что влечет за собой конкуренцию с системами баз данных за ресурсы и снижение общей производительности.
Читайте также: