Зависит от конфигурации сервера. Например, так:
Код:
# Количество потоков на worker
accounting.worker.1.thread.count=2
# Тарификатор:
accounting.worker.1.tariffication.1.minDeltaAmount=3145728
accounting.worker.1.tariffication.1.delay=10
accounting.worker.1.tariffication.1.batchSize=500
accounting.worker.1.tariffication.2.minDeltaAmount=0
accounting.worker.1.tariffication.2.delay=15
accounting.worker.1.tariffication.2.batchSize=1000
# Трекер (обработка сессий без наработки):
# Пауза между заданиями трекинга
accounting.worker.1.tracking.1.delay=20
# Максимальное количество проверенных соединений за задание
accounting.worker.1.tracking.1.batchSize=500
# Количество потоков на worker
accounting.worker.2.thread.count=1
# Сброс в базу трафиков и наработки:
# Минимальная наработка, при которой сбрасывать соединения в базу
accounting.worker.2.flushing.1.minDeltaAccount=0
# Минимальная сумма трафика, при которой сбрасывать соединение в базу
accounting.worker.2.flushing.1.minDeltaAmount=0
# Пауза между заданиями сброса в базу
accounting.worker.2.flushing.1.delay=20
# Максимальное количество сброшенных соединений в базу за задание
accounting.worker.2.flushing.1.batchSize=1000
# Количество потоков на worker
accounting.worker.3.thread.count=1
# Завершатель соединений:
# Пауза между заданиями
accounting.worker.3.finishing.1.delay=20
# Максимальное количество сброшенных соединений в базу за задание
accounting.worker.3.finishing.1.batchSize=500
По идее, worker'ы не могут загрузить на 100% больше чем SUM(accounting.worker.x.thread.count) ядер, даже если указать batchSize=0 (обработать за раз все сессии) и delay=1 (через каждую секунду). При этом обсчет (tariffication и tracking) старается почти не обращаться к БД, но следит за балансом договора. Т.е. можно попробовать увеличить batchSize и уменьшить delay, но какой-нибудь запас оставлять, плюс смотреть логи, на всякий случай, на возникновение ошибок (например, Lock wait timeout).
Вход
Регистрация
FAQ
Поиск
