LINUX.ORG.RU
ФорумAdmin

Ускарение работы системы


0

1

Народ ситуация в следующим стоит у меня debian 5 и postgresql при большом количестве подключений у меня переполняется кэш дисков и начинает тормазить база, т.е документы медленно проводится начинают, я помню, что есть такая штука увиличение дискрипторов или кредов, точно не скажу, как мне их увеличить? ил что лучше сделать, что б избавиться от данной проблемы, жесткие у меня на 10 рэйде.

Ответ на: комментарий от Ximen

Ну да тормозит, а если я запускаю обработку проведения большого количества документов, то база начинает тормозить и когда я один работаю.

vlershov
() автор топика
Ответ на: комментарий от vlershov

И что скажут tcp соединения о загрузке? - не понял вопроса

Так он и не тебе адресован.

Ximen ★★★★
()
Ответ на: Доктор Вейдер плохого не посоветует! от Mobyshvein

ss state connected sport = :5432


State       Recv-Q Send-Q                           Local Address:Port                               Peer Address:Port
ESTAB       0      0                              192.168.111.251:postgresql                           192.168.111.1:4249  
ESTAB       0      0                              192.168.111.251:postgresql                           192.168.111.1:3685  
ESTAB       0      0                              192.168.111.251:postgresql                           192.168.111.1:4879  
ESTAB       0      0                              192.168.111.251:postgresql                           192.168.111.1:2726  
ESTAB       0      0                              192.168.111.251:postgresql                           192.168.111.1:2727  
ESTAB       0      0                              192.168.111.251:postgresql                           192.168.111.1:2808  
ESTAB       0      0                              192.168.111.251:postgresql                           192.168.111.1:4852  
ESTAB       0      0                              192.168.111.251:postgresql                           192.168.111.1:1126  
ESTAB       0      0                              192.168.111.251:postgresql                           192.168.111.1:2451  
ESTAB       0      0                              192.168.111.251:postgresql                           192.168.111.1:4901  
ESTAB       0      0                              192.168.111.251:postgresql                           192.168.111.1:1774  
ESTAB       0      0                              192.168.111.251:postgresql                           192.168.111.1:2317  
ESTAB       0      0                              192.168.111.251:postgresql                           192.168.111.1:2528  
ESTAB       0      0                              192.168.111.251:postgresql                           192.168.111.1:4505  
ESTAB       0      0                              192.168.111.251:postgresql                           192.168.111.1:4876  
ESTAB       0      0                              192.168.111.251:postgresql                           192.168.111.1:4886  
ESTAB       0      0                              192.168.111.251:postgresql                           192.168.111.1:3362  
ESTAB       0      0                              192.168.111.251:postgresql                           192.168.111.1:3479  

vlershov
() автор топика
Ответ на: комментарий от anton_jugatsu

При чём здесь загрузка, речть шла про «примерно» 25-30 подключений.

А чем поможет ss state connected sport = :5432?

Ximen ★★★★
()
Ответ на: комментарий от Ximen

между сервером и клиентом тем более, для сервера в нашем случаи клиентом будет сервер 1С который стоит на другом сервере. Я сижу от серверов в 10 метрах за стенкой.

vlershov
() автор топика
Ответ на: комментарий от Ximen

Я уже настраивал подобную систему, и там все работает нормально, единственная разница это железо, в первом случаи все было региональное от IBM в этом случаи все от DEPO

vlershov
() автор топика
Ответ на: комментарий от Ximen

Да смотрел. ТАм нет ни чего, что б мне помогло. Рыл google и yandex когда мысли кончились решил у вас спросить

vlershov
() автор топика
Ответ на: комментарий от vlershov

единственная разница это железо

Имхо трабла где-то в дисковой подсистеме, но это надо смотреть на месте.

Ximen ★★★★
()

Убедитесь, что у контроллера есть батарейка и включите на нём кеш.

То, что у вас начинаются тормоза при росте дискового кеша в ОЗУ компьютера не означает, что они вызванны именно этим ростом. У вас не хватает производительности RAID, и на этом всё затыкается.

mky ★★★★★
()
Ответ на: комментарий от vlershov

Интересно когда же мы увидим конфиг сервера и iostat 1 в момент тормозов. У вас по free 14 гигов файлового кеша. Покажите конфиги же, там наверное постгресу гиг отдан.

ventilator ★★★
()
Ответ на: комментарий от mky

Та цифра которая показана на скриншоте iotop - это смех, а не нагрузка, ее сделает сата диск одиночка пятилетней давности. iops не видно конечно но судя по bps там копейки

ventilator ★★★
()
Ответ на: комментарий от vlershov

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

annoynimous ★★★★★
()
Ответ на: комментарий от annoynimous

На сколько мне известно кеширование рэйда тормозит его, хотя я могу ошибаться. Raid 10 дополнительный на нем лежит база. Система стоит на 1-ом Raid, 10 подмантирован, логи т.е. папка pg_xlog прямой ссылкой перенесена на raid где система стоит. Как можно еще его оптимизировать?

vlershov
() автор топика
Ответ на: комментарий от ventilator

Конфиг:

 
listen_addresses = '*' 
max_connections = 225 
shared_buffers = 712MB 
max_connections*16kB 
temp_buffers = 32MB 
work_mem = 1512MB 
maintenance_work_mem = 128MB 
max_fsm_pages = 204800 
max_fsm_relations = 1000 
fsync = on 
synchronous_commit = off 
wal_buffers = 2048kB 
wal_writer_delay = 2000ms 
checkpoint_segments = 256 
effective_cache_size = 9512MB 
autovacuum = on 
autovacuum_naptime = 30min 
default_with_oids = on 
escape_string_warning = off 
Все остальные параметры по умолчанию.

vlershov
() автор топика
Ответ на: комментарий от vlershov

> На сколько мне известно кеширование рэйда тормозит его, хотя я могу ошибаться.

Что-о-о? Кэширование УСКОРЯЕТ работу, причем многократно. Отключают его только в том случае, если контроллер имеет собственную память, но не имеет батареи резервного питания на случай пропажи основного, т.к. при агрессивном кэшировании высока вероятность массовых потерь информации с крахом файловой системы и базы.

Систему ставить на raid вообще нет смысла — нужно просто иметь резервный образ, который можно быстро развернуть.

Если база лежит на файловой системе, то при создании файловой системы нужно выравнивать по размеру блока, который использует рейд (stride), отключить обновление access time, включить барьеры (barriers), перевести журнал в режим writeback или вообще отключить.

annoynimous ★★★★★
()
Ответ на: комментарий от vlershov

shared_buffers = 712MB несколько странно для системы с 16гб памяти, поставьте хотя бы 8гб, sysctl подкрутить придется. effective_cache_size = 9512MB этой строчкой вы фактически говорите планировщику использовать фуллскан везде, потому что он считает что в кеше всегда лежит 9Гб данных для каждого запроса, уменьшите это значение(дефолтные 256mb вполне подойдут), вообще настроки планировщика не стоит трогать когда не знаешь точно зачем. enable_seqscan = off можно добавить. max_prepared_transactions проверьте, если 1с умеет подготовленные транзакции.

ventilator ★★★
()

> я помню, что есть такая штука увиличение дискрипторов или кредов, точно не скажу, как мне их увеличить?

Подпишись на спам «Enlarge your penis»

Led ★★★☆☆
()
Ответ на: комментарий от ventilator

Памяти мне дает поставить лишь shared_buffers 2 ГБ, я так понимаю ограничение 32-х битной оси. Но да же после изменения конфига результат такой же

vlershov
() автор топика
Ответ на: комментарий от vlershov

>ограничение 32-х битной оси.
И на ней ради одного приложения 16 гигабайт памяти?! Как оно их адресовать будет?

x3al ★★★★★
()
Ответ на: комментарий от vlershov

32-х битной оси

стоит 2-ксеона по 4 ядра каждый, 16 гб оперативы,

facepalm.jpg

rafister
()
Ответ на: комментарий от MikeDM

С базой не справляется 64-х битный mssql server

vlershov
() автор топика
Ответ на: комментарий от vlershov

Иногда постгрес сильно тормозит с битыми индексами. Мне много раз помогало пересоздание индексов.

Slavaz ★★★★★
()
Ответ на: комментарий от Hokum

Обусловленности собственно говоря не было, кеды вообще тут не приделах, можно гном, а почему debian 32? просто 64-й образ не устанавливался, он да же не предлагал выбора типа установки, просто ни чего не делал, а времени заново скачавать образ уже не было.

vlershov
() автор топика

Не могу промолчать!

В России две беды - дороги и безграмотные админы. Как страшно жить!

Attila ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.