Здравствуйте. Всем спасибо за советы, постараюсь свести их в некую систему и поэтапно применить, чтоб понять что и какой эффект даст в результате.
Попробую подвести итоги по теме: На вопрос "До примерно 50 тыс/сек сообщений статистика прокси и бекэндов сходится, а вот начиная примерно с 50тыс/сек начинаются расхождения.... Кто-то с таким сталкивался? " Я ожидал ответов в стиле "У меня на сервере при нагрузке 70 (80, 90 и т.д.) тыс/сек ничего подобного не наблюдается (или наблюдается что-то подобное)" Или что-то близкое по смыслу. Судя по содержанию данных советов: Подобную статистику не ведут, т.к. не видят особого смысла. Зачем мне это нужно: Есть 3 реверс-прокси, и от 15 до 30 беков, на которые и проксируются запросы. Обращения жестко делятся на несколько типов, тип определяется значением переменной в запросе, запросы БЕЗ этой переменной игнорируются. Беки ведут статистику сколько и какого типа запросов они получили, эти данные сливаются в БД и хранятся с дискретностью 20минут. Регулярно требуется "нестандартная" статистика, например "средний размер ($body_bytes_sent) по запросам типа "sc012" за сутки" "соотношение обращений по http и https ($schema) по запросам типа "q1wr" за час" "наименьшее/среднее/наибольшее время ($request_time) по запросам типа "sc012" за..." "объем запросов типа "q1wr" (сумма $body_bytes_sent таких запросов) в общем объеме трафика (сумма $body_bytes_sent всех запросов)" и т.д. нет смысла каждый раз перекраивать ПО на беках, ведь все это есть в логах реверс-прокси. Сами файлы логов живут максимум 15-20 минут, этого достаточно для извлечения необходимых данных. Нестыковки стали вылезать, когда один из 3-х фронтов погасили на пару дней, нагрузка на оставшиеся 2 стала выше 50тыс/сек на каждом из них (при этом их предел гораздо выше, каждый может гарантировано "переварить" 200тыс/сек) и пошли расхождения в отчетах по количеству запросов с фронтов и беков. При снижении количества запросов все снова хорошо согласуется. Получены советы: 1) Уточнить методику расчета -- не вижу смысла, сколь-нибудь существенные и системные расхождения появляются только когда нагрузка на реверс-прокси выше 50тыс/сек, т.е. 3 х 40 проблем нет,а 2 х 60 уже проблема? при этом когда "железки" 2 шт, а nginx-ов на них 3шт проблема снова исчезает... 2) Тюнинг сокетов -- в процессе, UDP исключен, замер связки unixSocket+rsyslog на один unixSocket пока показал "потолок" 150тыс/сек производительность, но еще не все идеи реализовал-проверил. 3) Настройки rsyslog-а $SystemLogRateLimitInterval 0 $SystemLogRateLimitBurst 0 $SystemLogRateLimitBurst -- ставился и "0", и "20000000", на конечный результат не повлияло. как и замена на другой syslog. Всё точно идёт сразу в syslog/rsyslog напрямую, а не через systemd-journal ? Точно, в systemd-journal эти данные не фиксируются и туда вообще не попадают. Производительности хранилища точно достаточно для 150тыс/сек (один из способов замера -- запуск одновременно 3-х экземпляров rsyslog на одном физическом сервере и заливка в 3 сразу тестового набора в 12млн сообщений на каждый, итог 300-450тыс/сек в совокупности, непрерывно в течении нескольких часов заливка-ротация-удаление) Все работает на физическом железе, без VPS-ов и контейнеров. По результатам отпишусь, но врядли скоро, т.к. такая нагрузка не регулярна, а вариантов для проверки не 1 и не 2 :) Всем спасибо за внимание. _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
