ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Хелп ЦПУ 100%
11 сообщений из 11, страница 1 из 1
Хелп ЦПУ 100%
    #39577719
AlexGru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlexGru
Участник
Всем привет.

Подскажите адекватные ли настройки памяти?
PostgreSQL 9.6.4
CentOS Linux release 7.3.1611

Было 4 ядра и 16 Гб памяти.

Веб система, много мелких запросов блоками + небольшие вставки данных.
В онлайн порядка 50-150 сессий.

Проблема, всё виснет, цпу 100%.
Увеличение до 8 ядер не помогло. Особой нагрузки на диск нету.

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
name                         |setting |unit |
—---------------------------|--------|-----|
checkpoint_completion_target |0.7     |     |
effective_cache_size         |1572864 |8kB  |
maintenance_work_mem         |1048576 |kB   |
max_wal_size                 |128     |16MB |
min_wal_size                 |64      |16MB |
shared_buffers               |524288  |8kB  |
wal_buffers                  |2048    |8kB  |
work_mem                     |16777   |kB   |



Вывод free
Код: plsql
1.
2.
3.
              total     used        free      shared  buff/cache   available
Mem:       16425240     2365348     8098792     2499132     5961100    11166092
Swap:       8388604           0     8388604



Куда копать?
...
Рейтинг: 0 / 0
29.12.2017, 09:50
| Ответить | Цитировать | Написать  
Хелп ЦПУ 100%
    #39577726
Andy_OLAP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andy_OLAP
Участник
AlexGru,

Копать в сторону force_parallel_mode=off параллельного разбора данных, что вызывает повышенную нагрузку на CPU (версия 9.6 как никак), в сторону включения больших страниц в оперативной памяти huge_page=on.

Но главное - настройки автовакуума. Вы их не вывели, а в них собака то порылась. У Вас очень много непочищенных строк в туплах, при выборке с диска CPU захлебывается на их разборке, плюс захлебывается на разборке некластерных индексов ("много мелких запросов блоками").

Читайте Роберта Хааса, он расписал, как они для 9.6 соорудили некий типа хороший патч , который поменял картину того, как работает автовакуум.

Если Вы копипастили себе настройки с 9.5 и более старых - нужно вдумчиво перебирать их конкретно под 9.6. Увы.
...
Рейтинг: 0 / 0
29.12.2017, 10:01
| Ответить | Цитировать | Написать  
Хелп ЦПУ 100%
    #39577727
AlexGru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlexGru
Участник
Andy_OLAP,
Спасибо, да Hp не используются
Код: sql
1.
2.
3.
4.
5.
6.
7.
grep Huge /proc/meminfo
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB



Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
select name,setting,unit from pg_settings where name LIKE '%vacuum%'

name                                |setting   |unit |
------------------------------------|----------|-----|
autovacuum                          |on        |     |
autovacuum_analyze_scale_factor     |0.1       |     |
autovacuum_analyze_threshold        |50        |     |
autovacuum_freeze_max_age           |200000000 |     |
autovacuum_max_workers              |3         |     |
autovacuum_multixact_freeze_max_age |400000000 |     |
autovacuum_naptime                  |60        |s    |
autovacuum_vacuum_cost_delay        |20        |ms   |
autovacuum_vacuum_cost_limit        |-1        |     |
autovacuum_vacuum_scale_factor      |0.2       |     |
autovacuum_vacuum_threshold         |50        |     |
autovacuum_work_mem                 |-1        |kB   |
log_autovacuum_min_duration         |-1        |ms   |
vacuum_cost_delay                   |0         |ms   |
vacuum_cost_limit                   |200       |     |
vacuum_cost_page_dirty              |20        |     |
vacuum_cost_page_hit                |1         |     |
vacuum_cost_page_miss               |10        |     |
vacuum_defer_cleanup_age            |0         |     |
vacuum_freeze_min_age               |50000000  |     |
vacuum_freeze_table_age             |150000000 |     |
vacuum_multixact_freeze_min_age     |5000000   |     |
vacuum_multixact_freeze_table_age   |150000000 |     |
...
Рейтинг: 0 / 0
29.12.2017, 10:08
| Ответить | Цитировать | Написать  
Хелп ЦПУ 100%
    #39577728
AlexGru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlexGru
Участник
+
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
select name,setting,unit from pg_settings where name LIKE '%parall%'

name                            |setting |unit |
--------------------------------|--------|-----|
force_parallel_mode             |off     |     |
max_parallel_workers_per_gather |0       |     |
min_parallel_relation_size      |1024    |8kB  |
parallel_setup_cost             |1000    |     |
parallel_tuple_cost             |0.1     |     |
...
Рейтинг: 0 / 0
29.12.2017, 10:09
| Ответить | Цитировать | Написать  
Хелп ЦПУ 100%
    #39577736
Alexius
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexius
Участник
AlexGru,

вангую наличие очень длинных транзакций или отсутствие каких-то важных индексов. смотрите, какие запросы у вас больше всего нагрузки дают (в pg_stat_statements и логах с log_min_duration_statement). и покажите на всякий случай шапку от вывода команды top в момент проблемы, а то под cpu 100% можно разные вещи понимать.
...
Рейтинг: 0 / 0
29.12.2017, 10:19
| Ответить | Цитировать | Написать  
Хелп ЦПУ 100%
    #39577744
AlexGru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlexGru
Участник
Alexius,
Код: sql
1.
2.
3.
4.
5.
top - 12:36:20 up  1:36,  2 users,  load average: 40.51, 34.93, 90.32
Tasks: 249 total,  53 running, 196 sleeping,   0 stopped,   0 zombie
%Cpu(s): 98.3 us,  1.5 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.2 si,  0.0 st
KiB Mem : 16425240 total, 10687668 free,   693280 used,  5044292 buff/cache
KiB Swap:  8388604 total,  8388604 free,        0 used. 13551924 avail Mem
...
Рейтинг: 0 / 0
29.12.2017, 10:37
| Ответить | Цитировать | Написать  
Хелп ЦПУ 100%
    #39577753
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
AlexGruAlexius,
Код: sql
1.
2.
3.
4.
5.
top - 12:36:20 up  1:36,  2 users,  load average: 40.51, 34.93, 90.32
Tasks: 249 total,  53 running, 196 sleeping,   0 stopped,   0 zombie
%Cpu(s): 98.3 us,  1.5 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.2 si,  0.0 st
KiB Mem : 16425240 total, 10687668 free,   693280 used,  5044292 buff/cache
KiB Swap:  8388604 total,  8388604 free,        0 used. 13551924 avail Mem



Так вам не сервер настраивать надо а смотреть какие запросы тормозят и почему. И или переписывать запросы или добавлять индексы. Лог базы и pg_stat_statements вам в руки.
1 таблица с миллионом строк и забытым индексом может поставить на колени суперсервер на 64 ядра.
Т.е. искать надо там где потеряли а не в настройках.

--
Проект с базой но без DBA все равно что автопарк без автомеханика. Все ездит до первой поломки.
dataegret.ru
...
Рейтинг: 0 / 0
29.12.2017, 10:57
| Ответить | Цитировать | Написать  
Хелп ЦПУ 100%
    #39577770
AlexGru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlexGru
Участник
Спасибо. Будем капать, тоже склоняюсь к проверке кода в первую очередь.
Интересно было, так ли выставлены параметры памяти в первую очередь.
Смущает, что нагрузка большая, а used=2365348
...
Рейтинг: 0 / 0
29.12.2017, 11:17
| Ответить | Цитировать | Написать  
Хелп ЦПУ 100%
    #39577808
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
AlexGru<...> много мелких запросов блоками + небольшие вставки данных.
В онлайн порядка 50-150 сессий.

Проблема, всё виснет, цпу 100% .
Увеличение до 8 ядер не помогло. Особой нагрузки на диск нету .

искал бы "мелкие запросы" с изрядными аналитическими затратами. причем не по большим выборкам (мне обычно дисковую удаётся нагнуть в первую голову, за счет ресортов и мат-ции объемистых промежностей вычислений) а именно дорогие вычислительно ф-ии. и , видимо, на стороне данных.

например полнотекст по неиндексированным полям будет дорог и вычислительно тоже.

языки процедурные посторонние в ПЖ есть ?

и да, баунсеры/пулеры бы надоть, и транзакции клиентские в хранимочки запхать, чтобы концов не торчало. по возможности.
...
Рейтинг: 0 / 0
29.12.2017, 12:26
| Ответить | Цитировать | Написать  
Хелп ЦПУ 100%
    #39578111
Andy_OLAP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andy_OLAP
Участник
AlexGru,

Кстати, а сервер то одиночный? У Вас случаем wal sender не работает на полную катушку?
...
Рейтинг: 0 / 0
29.12.2017, 23:17
| Ответить | Цитировать | Написать  
Хелп ЦПУ 100%
    #39578112
Andy_OLAP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andy_OLAP
Участник
AlexGruСпасибо. Будем капать, тоже склоняюсь к проверке кода в первую очередь.
Интересно было, так ли выставлены параметры памяти в первую очередь.
Смущает, что нагрузка большая, а used=2365348
Ловите длинные запросы
Код: sql
1.
SELECT max(now() - xact_start) FROM pg_stat_activity WHERE state IN ('idle in transaction', 'active')
...
Рейтинг: 0 / 0
29.12.2017, 23:18
| Ответить | Цитировать | Написать  
11 сообщений из 11, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Хелп ЦПУ 100%
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&msg=39577770&tid=1996015]:
 0ms
get settings:
 9ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 190ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 44ms
get tp. blocked users:
 1ms
others: 16ms
total:  293ms
созд. / загр.: 293ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]