Уже какое время бьюсь с проблемой, и всеравно никак.Использую машинку с фрей как биллинг сервер, на котором крутится фри радиус.
Статистика собирается с кошек, которые шлют старты, стопы и авторизации для любых входящих соединений. будь то звонки или vpn.В часы наибольшей загрузки. наблюдается огромное отбрасывание соединений. Загрузка же самого сервера даже не приближается к 1, а остается в пределах 0,2 - 0,3. Пробовал SMP и без него.
Ставил систему аж на 8 процессорную мать. Все также.Уевеличивал
kern.ipc.maxsockets
kern.ipc.maxsockbufnetstat -s -p udp
выдает такое
41262 dropped due to full socket buffersИ этот счетчик продолжает расти. Изменение вышеперечисленных параметров лишь оттягивает начальную дату наступления этого момента.
load averages: 0.12, 0.16, 0.15
процессоры загружены на 3.81% сервисом radiusdВ данном случаи очень важно, не просто быстрый ответ сервера на запрос , а также прием всех пакетов UDP, так как практически каждый из них содержит информацию о начислениях. Происходит потеря данных соответственно денег.
Посоветуйте что делать , куда копать, что менять.
а большой траффик (пакетов/сек)? может радиус забирать не успевает?
>а большой траффик (пакетов/сек)? может радиус забирать не успевает?Траффик да большой, до 100 пакетов в секунду. но на сети , и на сервере нагрузки не видно.
Я пересобирал ядро с полингом , и HZ делал = 5000. и никак.
Впечатление , что просто сама система не может работать с такой нагрузкой udp пакетов
>>а большой траффик (пакетов/сек)? может радиус забирать не успевает?
>
>Траффик да большой, до 100 пакетов в секунду. но на сети ,
>и на сервере нагрузки не видно.
>Я пересобирал ядро с полингом , и HZ делал = 5000. и
>никак.
>Впечатление , что просто сама система не может работать с такой нагрузкой
>udp пакетовда не, это небольшой, фря до 20-30К pps держит.
к сожалению, к фрирадиусом не работал, поэтом только могу высказать предположения =)
куда статистика пишется - в базу, которая лежит на каком-нить raid на паре дисков? тогда очень может быть, что это и есть узкое место - 100 транзакций в секунду это как раз цифры близкие к производительности современных hdd.
в базу писаться не успевает, радиус лочится и не успевает забирать пакеты..ну это можно понять по расширенным статам (top, iostat)
Данные складируются в базу данных, которая висит на отдельном сервере с RAID0.
Slackware, диск прикручен как XFS -noatime.
Все инсерты идут с пониженным приоритетом. Нагрузок видимых на винты не наблюдалось.
Процессы базы данных едят 3% CPU.
нда )
тем не менее, думаю, что дело не в операционке, а в неуспевании фрирадиусом обрабатывать запросы
играться с thread pools пробовали?
>нда )
>тем не менее, думаю, что дело не в операционке, а в неуспевании
>фрирадиусом обрабатывать запросы
>играться с thread pools пробовали?Канечно . запущено 4м процесами ( по процессу на CPU )
Сейчас активно мониторю дисковые операции. Может все дело и в них ...хотя странно.
Уже подумываю собрать кластер .хотя смутно верю что это добавит производительности.
>>нда )
>>тем не менее, думаю, что дело не в операционке, а в неуспевании
>>фрирадиусом обрабатывать запросы
>>играться с thread pools пробовали?
>
>Канечно . запущено 4м процесами ( по процессу на CPU )
> Сейчас активно мониторю дисковые операции. Может все дело и в них
>...хотя странно.
>Уже подумываю собрать кластер .хотя смутно верю что это добавит производительности.dtrace бы сюда =)
а если радиус на компе с БД запускать и коннектиться к БД локально?
100 в секунду - цифры действительно несерьёзные для сетевого стека/нормально написанного софта
Вы рассказывайте плиз о борьбе, нам полезно будет )