Comments 11
Как поступить, если решение проблемы возможно с нарушением рамок существующей технологии?
Почему вы считаете, что чем больше буффер, тем лучше?
Для осознания проблемы: en.wikipedia.org/wiki/Bufferbloat
Для осознания проблемы: en.wikipedia.org/wiki/Bufferbloat
Честно признаться, перечитал свою статью на всякий случай, но отверждения «чем больше буффер, тем лучше» я не нашел. Истина, как всегда, где-то посередине.
Что для вас является проблемой?
В моем случае увеличение нескольких буфферов повысило производительность (эффективность) сервера, решило проблемы с ростом задержек (за счет избавления от пересылки сброшеных пакетов) в момент резкого роста нагрузки.
Значит ли это, что я создал проблему за счет буферов или все-таки решил ее? В моем случае проблем стало меньше, а работа стабильнее.
Что для вас является проблемой?
В моем случае увеличение нескольких буфферов повысило производительность (эффективность) сервера, решило проблемы с ростом задержек (за счет избавления от пересылки сброшеных пакетов) в момент резкого роста нагрузки.
Значит ли это, что я создал проблему за счет буферов или все-таки решил ее? В моем случае проблем стало меньше, а работа стабильнее.
Увеличение буфферов всегда повышает производительность и всегда повышает latency за счёт дольшего пребывания в очереди. С агрегированных дашбордов это выглядит как повышение производительности, с точки зрения отдельного запроса — как ухудшение параметров системы.
Вспомните про производительность супермаркета следующий раз в очереди на кассу. Чем больше очередь, тем выше производительность кассира. И тем «лучше» вы (стоя в очереди) думаете о супермаркете в котором очередь на пол-часа.
Вспомните про производительность супермаркета следующий раз в очереди на кассу. Чем больше очередь, тем выше производительность кассира. И тем «лучше» вы (стоя в очереди) думаете о супермаркете в котором очередь на пол-часа.
Производительность приложения (кассира) выражается не в размере буффера (очереди), а в скорости обработки объектов из этой очереди. Если вы второй в очереди, то у вас есть время выложить продукты на ленту. Если же 15-й, то система явно перегружена и ни о какой производительности речи быть не может, но тогда и размер буффера вас не спасет т.к. если он будет заполняться быстрее работы кассира, то очереди придется вырасти за пределы магазина, а это out of memory.
Производительность кассира определяется числом обслуженных покупателей. Если в час пик очередь 5 человек, а вне часа пик бывают моменты, что кассир бездельничает, то мы можем повысить производительность кассира увеличив размер очереди. Если очередь будет 100 человек, то даже вне часа пик кто-то в этой очереди всё ещё будет стоять (час ожидания) и производительность кассира будет больше.
А дальше google: microbursts (это к вопросу откуда «очередь»), плюс война буферов и tcp. tcp бы и радо сделать retransmit, но ей присылают дупликаты. Приходится снижать скорость. (при этом утилизация канала растёт, все рады, кроме конечного клиента).
А дальше google: microbursts (это к вопросу откуда «очередь»), плюс война буферов и tcp. tcp бы и радо сделать retransmit, но ей присылают дупликаты. Приходится снижать скорость. (при этом утилизация канала растёт, все рады, кроме конечного клиента).
Могу предположить, что ключевая фраза —
в момент резкого роста нагрузки
Поясните, пожалуйста, как именно по количеству соединений в состоянии SYN_RECV определить заполненность очереди между сетевой картой и ядром?
Очень хороший вопрос, который заставил меня перечитать диаграмму TCP состояний в Linux.
В одной из статей по оптимизации я прочел об этом методе, но фактически соединение будет в состоянии SYN_RECV и после того, как ядро обработает его и отправит SYN+ACK в обратную сторону, поэтому этот метод не подходит для определения загруженности очереди netdev_max_backlog.
Я внесу в статью правки согласно вашему коментарию, благодарю.
В одной из статей по оптимизации я прочел об этом методе, но фактически соединение будет в состоянии SYN_RECV и после того, как ядро обработает его и отправит SYN+ACK в обратную сторону, поэтому этот метод не подходит для определения загруженности очереди netdev_max_backlog.
Я внесу в статью правки согласно вашему коментарию, благодарю.
Sign up to leave a comment.
I’m going deeper underground, или о чем стоит знать, оптимизируя работу сетевого приложения