Падает ядро

[Semi]

Помогите! Может кто сталкивался с моей проблемой. Железо 8 ядерный j7 950, FreeBSD 8.1, ядро пытается обработать трафик и грузин один процессор на 100 %, после чего никак не реагирует пока не общитает тот объем трафика который к нему приплыл и за собой влечет много последствий и глюков вроде не подключение клиентов после погашения задолженностей, не подключает авторизаторы клиента и т. д. Всякие настройки и изменение временных параметров сбора трафиком ядром я уже испробовал, ничего не помогает.  Отключить сбор трафика нельзя так как когда заводишь нового клиента он делает перерасчет по датам и запускает денежный общет данного клиента при появлении первого трафика.

Внизу загрузил скрин обработки ядром трафика, ну и момент когда оно падает

[stix]

попробуй уменьшить время обработки данных.
детализация трафика отключена?

[Semi]

Пробовал. Увеличивал время, и отключал в тарифах детализацию трафика. не помогло . Трафик собирается я так понял в usr/local/nodeny/sql и очень огромными объемами гда-то от 5 до 15 гегабайт. И еще заметил ядро начинает падать когда трафик превышает отметку в 400 Мегабит/сек.
Возможно ли решение проблемы заставить обрабатывать ядро билинга большим количеством процессоров. Или разделить обработку трафика и остальные функции ядра на разные процессоры. Я так понял мне наращивании мощности компьютера не поможет, а если и поможет то не надолго.

[stix]

irqbalance запущен?

[Andrey Zentavr]

irqbalance запущен?

А чем должен помочь irqbalance? Это как бы штука для прерываний, которые генеряться железом, а не софтом.

Irqbalance является демоном, который применяется для распространение аппаратных прерываний между процессорам и ядрами системы. Основная задача irqbalance создать баланс между энергосбережением и оптимальной производительностью.
Подробнее: http://www.securitylab.ru/processinfo/419735.php
И здесь: https://irqbalance.org/

[stix]

да, верно )
думал о другом, привык за сетевые карточки отвечать.

насколько помню, ядро Nodeny не может размазываться на треды

[stix]

кстати вот да, реально тема актуальная насчет размазывания по ядрам тредов.
это касается как флоу разгребальщиков, так и основного ядра биллинга.

раньше этому не особо уделял внимание.
но если так посудить, то эффективности установки intel core i7 под биллинг будет крайне мало.
кроме как выделение под Perl скрипт отдельного ядра.

[Andrey Zentavr]

кстати вот да, реально тема актуальная насчет размазывания по ядрам тредов.
это касается как флоу разгребальщиков, так и основного ядра биллинга.

раньше этому не особо уделял внимание.
но если так посудить, то эффективности установки intel core i7 под биллинг будет крайне мало.
кроме как выделение под Perl скрипт отдельного ядра.

Если используются Perl threads (use threads;), то фактически для операционной системы мы имеем тот же один процесс на том же одном процессоре.
В нашем случае нужно использовать fork(). Но тут всплывают особенности с открытыми дескрипторами соединений к базе данных, лог-файла и, возможно, чему-то ещё (я так глубоко ядро не ковырял).
Пример - как-то вот так:
https://wiki.bc.net/atl-conf/pages/viewpage.action?pageId=20548191

[stix]

угу, нужно городить велосипед с синхронизацией потоков.

[0xbad0c0d3]

попробуй уменьшить время обработки данных.
детализация трафика отключена?

Пробовал. Увеличивал время, и отключал в тарифах

oO что-то не понятно, пробовал и уменьшать, и увеличивать? или "пробовал - увеличичвал"... Увеличивать нет смысла - будет еще больше нагрузка... $Kern_t_traf вообще в 0 поставить
Это делается тут: Операции->Настройки->Ядро: С каким периодом (в секундах) снимать показания потребленного трафика клиентами.  Чем меньше число, тем оперативней будет информация, но тем больше нагрузка на сервер. Если установить в 0, то статистика будет сниматься сразу же после окончания подсчета и записи предыдущего среза

[Andrey Zentavr]

Дык и так проц в соточку загружен судя из картинки.
Данная подстройка исправит ситуацию?

[0xbad0c0d3]

Так будет маленький срез: маленький срез - меньше инфы на обработку - меньше нагрузка
хуже не будет - точно! )))

[Andrey Zentavr]

Сделали пока так

[Andrey Zentavr]

[root@cassiopeia ~]# ./mysqltuner.pl

 >>  MySQLTuner 1.2.0 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.1.53
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 3G (Tables: 50)
[--] Data in InnoDB tables: 285G (Tables: 429)
[!!] Total fragmented tables: 439

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 3d 22h 40m 46s (29M q [85.332 qps], 94K conn, TX: 18B, RX: 14B)
[--] Reads / Writes: 22% / 78%
[--] Total buffers: 2.2G global + 11.2M per thread (151 max threads)
[OK] Maximum possible memory usage: 3.9G (45% of installed RAM)
[OK] Slow queries: 0% (6/29M)
[OK] Highest usage of available connections: 52% (79/151)
[OK] Key buffer size / total MyISAM indexes: 64.0M/1.7G
[OK] Key buffer hit rate: 100.0% (9M cached / 95 reads)
[OK] Query cache efficiency: 20.1% (1M cached / 7M selects)
[!!] Query cache prunes per day: 559652
[OK] Sorts requiring temporary tables: 0% (565 temp sorts / 195K sorts)
[OK] Temporary tables created on disk: 16% (38K on disk / 230K total)
[OK] Thread cache hit rate: 99% (79 created / 94K connections)
[!!] Table cache hit rate: 10% (272 open / 2K opened)
[OK] Open file limit used: 0% (76/11K)
[OK] Table locks acquired immediately: 99% (27M immediate / 27M locks)
[!!] Connections aborted: 6%
[!!] InnoDB data size / buffer pool: 285.5G/2.0G

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Enable the slow query log to troubleshoot bad queries
    Increase table_cache gradually to avoid file descriptor limits
    Your applications are not closing MySQL connections properly
Variables to adjust:
    query_cache_size (> 32M)
    table_cache (> 2048)
    innodb_buffer_pool_size (>= 285G)

[stix]

как вариант - вынести коллектор на другую машину.