ThePriest, тут дело не в размере, а в шаблоне использования. Я думаю, у вас далеко не стандартный сайт. Ну а если стандартный - памяти добавили бы лучше.
Но ведь это как раз и означает, что вы уделили значительное внимание оптимизации операций записи.
значит это большая бд тормозит как сеошная помойка. Это ни фига не норма.
ussr1990, это я мониторинг операций чтения и записи, которого у вас нет, имею ввиду.
arista, в таком случае крайне подозрительно, что вы на этом вообще акцентируете внимание. Не только вы выбираете хостера, но и хостер выбирает клиентов.
А придется.
Хостинг это массовый продукт. Цена рассчитывается исходя из небольшого числа начальных обращений. Когда вы задолбаете техподдержку сверх меры они от вас просто откажутся либо будут тихо динамить.
Тащемта, сама циска рекомендует настраивать именно uRPF, а не фильтры.
Но даже это все равно незначительно повышает нагрузку. А в случае такого генерируемого флуда может и значительно.
На самом деле наоборот. За исключением специальных случаев (сеошная помойка, рОздача кин) на выделенном вебсервере операций записи больше чем чтения.
Как правило, владельцы озабочены быстрым ответом и оперативная память уже содержит весь рабочий набор данных. Изменения этого же рабочего набора постоянно пишутся на диск.
Pilat, есть разница в характере трафика между подделкой одного пакета (свитчи и роутеры вообще не как не реагируют на них. им это не нужно для работы) и настройкой интерфейса например в процедуре arp-оповещения. Или машина вдруг ответит на arp-запрос. Вот тут уже какие-то механизмы контроля могут сработать.
Короче, раз заблокировали, значит не прокатит.
Скорее всего не прокатит. Будет как этом посте -
Pilat, ну вот просто поленились порт подделать. Проверить не так просто как кажется. Это не на баше шкрипт в три строки наваять.
Не факт, что с подделкой вообще никак не борятся. Но, похоже, превентивной фильтрации нет.
Если немного - скорее всего это широковещательный или отдельные ошибки администраторов соседних серверов. Внимательней проанализируйте.
