[ОТВЕТИТЬ]
Опции темы
19.01.2016 08:39  
Mr_Vito
в офисе стала тормозить база, стал смотреть процессы на сервере, оказывается один процесс жрет постоянно 300-400 мб/с на чтение винт
Код:
Total DISK READ: 346.18 M/s | Total DISK WRITE: 255.75 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
13650 be/4 oracle    363.12 K/s    0.00 B/s  0.00 % 37.23 % ora_s006_ilishco
14385 be/4 oracle    601.30 K/s    0.00 B/s  0.00 % 13.88 % ora_s022_ilishco
14334 be/4 oracle      7.81 K/s    0.00 B/s  0.00 %  1.00 % oracleilishco (LOCAL=NO)
14067 be/4 oracle    345.10 M/s    0.00 B/s  0.00 %  0.22 % oracleilishco (LOCAL=NO)
при том беспрерывно.
Выключаешь почтовый сервер, процесс исчезает, жрать перестает.
в чем может быть причина такой прожорливости?
 
19.01.2016 11:44  
OlegON
Очень большая очередь почтовика или очень маленькое время периода генерации пакетов или опроса входящих.
 
07.05.2016 11:59  
DMaslov
Примажусь к теме.

К производительности почтовика у меня тоже большой вопрос.

В очередь на рассылку поставлено порядка 5000 карточек. Поскольку каждая карточка заносится в очередь двумя строками, в журнале строк порядка 10 тыщ.

Переваривает он их уже полчаса, тоже со 100%-ной загрузкой диска, после формирования каждого набора виртуальных пакетов (каждый пакет размером порядка нескольких килобайт) для 19 БД журнал уменьшается примерно на 2000 строк. Впору его выносить на отдельный сервер, чтоб база поживей себя чувствовала.

По современным меркам объемы порядка тысяч строк (это ж не BLOBы какие - размер пакетов вполне соответствует ожиданиям) - это семечки, я бы ожидал, что время формирования архивов составляло секунды, а не десятки минут, как сейчас. Настройка "максимальное кол-во объектов в пакете" сейчас = 100. Но, боюсь, с такой оптимальностью работы она окажет на производительность небольшое влияние.
 
07.05.2016 12:46  
konst
кол-во объектов в пакете конечно зависит от пересылаемых данных... и подбирается эмпирическим путем
но по-моему 100 - это очень мало... у меня стоит 1000.
 
07.05.2016 12:48  
baggio
если канал широкий может убрать галку "архивировать" проще протолкнуть 20 метров чем ждать пару минут пока заархивирует? особенно если производительность проца в дифеците..
 
07.05.2016 13:42  
OlegON
+1 к тому, чтобы убрать архивацию, увеличить количество объектов в пакете (на время масштабной пересылки, как минимум), снизить количество потоков отправки и приема до 1 каждого, и унести почтовик на другой сервер, который можно будет ребутить ежедневно.
Если магазинные серваки не нищебродские и косячат редко, то 1000 - вполне нормальная цифра, можно и поболее...
 
08.05.2016 19:21  
DMaslov
Цитата:
Сообщение от baggio
ждать пару минут пока заархивирует?
У вас ощущение, что архив, занимающий в сжатом состоянии 5 Кб, делается пару минут?
 
10.05.2016 10:47  
baggio
Цитата:
Сообщение от DMaslov
У вас ощущение, что архив, занимающий в сжатом состоянии 5 Кб, делается пару минут?
Легко... возьмите файл размером в несколько гигабайт забитый целиком нулями - и попробуйте его заархивировать...
не забудьте включить секундомер...
 
10.05.2016 14:51  
DMaslov
Ну и зачем абстрактные нереальные примеры, когда речь о совершенно конкретном?
 
10.05.2016 15:35  
baggio
Цитата:
Сообщение от DMaslov
Ну и зачем абстрактные нереальные примеры, когда речь о совершенно конкретном?
Ну и зачем абстрактные нереальные примеры, когда речь о совершенно конкретном - взять - снять галку и проверить?
 
 


Опции темы



Часовой пояс GMT +3, время: 02:55.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.