Нет. Указание минуса перед именем файла отключает sync на диск при каждой записи в лог, что повышает производительность, но может привести к тому, что при сбое данные могут оказаться фактически не записанными на диск.
Выдержка из man syslog.conf на эту тему:
You may prefix each entry with the minus ''-'' sign to omit syncing the file after every
logging. Note that you might lose information if the system crashes right behind a write
attempt. Nevertheless this might give you back some performance, especially if you run
programs that use logging in a very verbose manner.
Тяжело сказать, «сколько трафика», потому как не ясна методика подсчета :)
Начать с того, что в данной ситуации влияние оказывает не столько трафик в мегабитах, сколько пакетрейт (pps), так как именно пакетики каждый раз генерировали прерывания, и проходили цепочки iptables и других структур ядра. Особенно портили жизнь кольца на свичах, так как loopdetect отрабатывал не сразу (а порой вообще не отрабатывал) и весь закольцованный трафик, перекидываемый быстрыми специализированными микрухами коммутаторов, летел через многострадальный бридж.
Статистики по пакетрейту, к сожалению, у меня нет. Зато есть данные по трафику в мегабитах, в rrd.
Методику подсчета «общего трафика» использовал такую: брал для каждого физического интерфейса среднее значение входящих байт за час, и прибавлял к нему среднее значение исходящих байт за час. За час — потому что так ужимает rrd, пиковые безусловно могли быть заметно больше, но данных не осталось. Потом сложил получившиеся значения для всех интерфейсов.
В итоге получилось 3.1Гбит/с
Посмотрев текущую загрузку на загруженном порту одного из коммутаторов, выявил, что средний размер пакета где-то 900 байт плюс-минус.
Следовательно, при 3.1Гбит/с и размере пакетика около 900байт получаем пакетрейт 450 тысяч пакетов в секунду.
Наверное, правильнее было бы его разделить на 2, так как при суммарном битрейте использовался входящий и исходящий трафик, а сам сервер пакеты практически не генерирует, то есть весь трафик — транзитный. Значит средний пакетрейт за час выходит около 250 тысяч пакетов в секунду, без учета возможных кратковременных всплесков.
Бридж был интересен тем, что создавалась «плоская» сеть, и большое количество ПО (игры, «сетевое окружение», бродкаст-чаты, и тому подобное, что использует бродкаст-пакеты для обнаружения) работало нормально. При этом можно было ограничивать доступ заблокированным абонентам до некоторых выборочных ресурсов сети (или наоборот, оставлять выборочные) которые находятся в его «псевдосегменте» сети.
К примеру:
-у шлюза адрес a.b.c.1/24
-у вас адрес a.b.c.2/24
-у вебсервера1 адрес a.b.c.3/24
-у вебсервера2 адрес a.b.c.4/24
В можете попасть на вебсервер2, а при попытке зайти на вебсервер1 попадаете на «страничку-информатор». При этом вроде как трафик даже через шлюз не проходил с точки зрения клиентской ОС.
Управляшки в то время были, но 300$ стоила управляшка с RS232+WEB (без snmp и telnet/ssh) которая умела поднимать/опускать порты, показывать статистику на портах и ТОЛЬКО port-based VLAN (без 802.1q). То есть по сегодняшним меркам даже недолевел2. Ни о каком ограничении доступа на уровне этих железок речи идти не могло, во всяком случае за вменяемые деньги.
Выдержка из man syslog.conf на эту тему:
встречный привет Роману от Трубласта
Начать с того, что в данной ситуации влияние оказывает не столько трафик в мегабитах, сколько пакетрейт (pps), так как именно пакетики каждый раз генерировали прерывания, и проходили цепочки iptables и других структур ядра. Особенно портили жизнь кольца на свичах, так как loopdetect отрабатывал не сразу (а порой вообще не отрабатывал) и весь закольцованный трафик, перекидываемый быстрыми специализированными микрухами коммутаторов, летел через многострадальный бридж.
Статистики по пакетрейту, к сожалению, у меня нет. Зато есть данные по трафику в мегабитах, в rrd.
Методику подсчета «общего трафика» использовал такую: брал для каждого физического интерфейса среднее значение входящих байт за час, и прибавлял к нему среднее значение исходящих байт за час. За час — потому что так ужимает rrd, пиковые безусловно могли быть заметно больше, но данных не осталось. Потом сложил получившиеся значения для всех интерфейсов.
В итоге получилось 3.1Гбит/с
Посмотрев текущую загрузку на загруженном порту одного из коммутаторов, выявил, что средний размер пакета где-то 900 байт плюс-минус.
Следовательно, при 3.1Гбит/с и размере пакетика около 900байт получаем пакетрейт 450 тысяч пакетов в секунду.
Наверное, правильнее было бы его разделить на 2, так как при суммарном битрейте использовался входящий и исходящий трафик, а сам сервер пакеты практически не генерирует, то есть весь трафик — транзитный. Значит средний пакетрейт за час выходит около 250 тысяч пакетов в секунду, без учета возможных кратковременных всплесков.
К примеру:
-у шлюза адрес a.b.c.1/24
-у вас адрес a.b.c.2/24
-у вебсервера1 адрес a.b.c.3/24
-у вебсервера2 адрес a.b.c.4/24
В можете попасть на вебсервер2, а при попытке зайти на вебсервер1 попадаете на «страничку-информатор». При этом вроде как трафик даже через шлюз не проходил с точки зрения клиентской ОС.
Управляшки в то время были, но 300$ стоила управляшка с RS232+WEB (без snmp и telnet/ssh) которая умела поднимать/опускать порты, показывать статистику на портах и ТОЛЬКО port-based VLAN (без 802.1q). То есть по сегодняшним меркам даже недолевел2. Ни о каком ограничении доступа на уровне этих железок речи идти не могло, во всяком случае за вменяемые деньги.