[ОТВЕТИТЬ]
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 Ну и зачем абстрактные нереальные примеры, когда речь о совершенно конкретном?
Ну и зачем абстрактные нереальные примеры, когда речь о совершенно конкретном - взять - снять галку и проверить?
11.05.2016 09:40
DMaslov
 
Снял галку архивации.
Как и ожидалось (мной), время формирования рассылки не уменьшилось.
Размер пакета стал вместо нескольких килобайт 1.5 Мб (неархивированный). Основное время он проводит на этапе "формирование ВП", в это время можно наблюдать потроха.

SQL:
SQL код:
Select COMPLEXARTICLEARTICLEAMOUNTISDEPENDENTPRICEPERCENT
  from Supermag
.SMCOMPLEXARTICLES
 where COMPLEXARTICLE 
'021779'  SELECT MAX(EVENTTIME)
          
FROM (SELECT EVENTTIME
                  FROM SMCARDSECURITYLOG
                 WHERE ARTICLE 
= :B1
                   
AND EMPLOYEE <> -3
                UNION ALL
                SELECT EVENTTIME
                  FROM SMASSORTMATRIXHIST
                 WHERE ARTICLE 
= :B1
                   
AND EMPLOYEE <> -3
                UNION ALL
                SELECT EVENTTIME
                  FROM SMDISCQUANTITYLOG
                 WHERE ARTICLE 
= :B1
                   
AND EMPLOYEE <> -3)


SELECT MAX(EVENTTIME)
  
FROM (SELECT EVENTTIME
          FROM SMCARDSECURITYLOG
         WHERE ARTICLE 
= :B1
           
AND EMPLOYEE <> -3
        UNION ALL
        SELECT EVENTTIME
          FROM SMASSORTMATRIXHIST
         WHERE ARTICLE 
= :B1
           
AND EMPLOYEE <> -3
        UNION ALL
        SELECT EVENTTIME
          FROM SMDISCQUANTITYLOG
         WHERE ARTICLE 
= :B1
           
AND EMPLOYEE <> -3)
           
Select ARTICLE,DOCTYPE,OPCODE from Supermag.SMCARDSALERATEOPERS where ARTICLE='096626' 


Чтобы не было, как в анекдоте "жаль, у меня еще столько хороших идей", возьмем на вооружение "кол-во объектов в пакете 1000" и "вынести на другой сервер".
11.05.2016 11:53
ReDHawK
 
Цитата:
Mr_Vito в офисе стала тормозить база, стал смотреть процессы на сервере, оказывается один процесс жрет постоянно 300-400 мб/с на чтение винт
Версию не пробовали указывать при проблеме?

До версии 1.033 были зависания почтовика при большом кол-ве пакетов, когда в почтовике висело долго "Отбор виртуальных пакетов". Помогала очистка статистики очереди почтовика. Если у вас младше 1.033. Попробуйте остановите почтовик, выполните: ANALYZE TABLE SUPERMAG.SMPOSTQUEUE DELETE STATISTICS; Запустите почтовик. Посмотрите не изменилось ли поведение почтовика.
11.05.2016 11:58
-Den-
 
Если на почтовике/его настройках/правилах рассылки/ лежал "большой болт" и вдруг его решили убрать то можно начать с
Цитата:
select * from smpostfailPack
select * from smpostfailin
select * from smpostfailindata
select * from smpostfailRP
select * from smpostfailrpdata
select * from smpostvirtpacks
select * from smpostpackages order by firststarted desc
select * from smpostqueue order by enqtime desc


SELECT TABLE_NAME,
ROUND((BLOCKS*8),2) kByte,
ROUND((NUM_ROWS*AVG_ROW_LEN/1024),2) KBReal,
ROUND((BLOCKS*8-NUM_ROWS*AVG_ROW_LEN/1024),2) Ha_kB
FROM USER_TABLES
where blocks is not null
order by Ha_kB desc
пс только аккуратно и осторожно, smpost...блаблабла может отличатся в десятки раз и надо подумать зачем и почему перед move/rebuild/analyze, а так реально помогает, но это если был жЁсткий криминал)))
11.05.2016 12:22
ReDHawK
 
Кстати, слышал кто-то перенес smpostqueue на другой диск и почтовик перестал так себя вести. alter table SMPOSTQUEUE move tablespace BIG_TABLES;
11.05.2016 21:29
OlegON
 
перенос на другой диск даст эффект только если речь идет о свободном и отдельном физическом диске. т.е. за счет разделения нагрузки.
Опции темы


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

 

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