NiTr0

"ip rule show|grep <table>|wc -l" - кол-во записей ссылающихся на таблицу. Подсчитать для первой, для второй, если в первой больше чем во второй - писать во вторую, иначе - в первую. Удалять - из обеих таблиц с выводом ошибок в /dev/null (ну или парсить записи, и удалять по нахождению).

Смотрите настройки ваших туннелей. С обеих сторон, да.

Отключить ipsec же.

250-300Вт потребление сервера - вас не смущает? Уж лучше купить FX8320 + десктопную мать более-менее пристойную + ЕСС память (нерегистровую) + более-менее БП (FSP какой-нить, только не PNR, PNF к примеру Вт на 350 с головой, ну или с APFC чего)... Более подходит для кладовочного сервера. Вы же надеюсь не на 1U сервер в кладовку нацелились? Помирать, так с музыкой? Смотря сколько писаться на них будет. И да, в RAID варианте забудьте о trim - т.е. ресурс SSD солидно сократится. Можете попробовать сделать рэйд 1 + flashcache к нему (или dm_cache заюзать - вроде как суть то же),

Само собой. Никто не может предсказать, сколько будет жрать тот или иной туннель через полчаса. Ну разве что если делать очень хитрые костыли и завязываться с коэф. использования полосы из статистики биллинга (суммарный траффик за месяц скажем, делить на суммарное время онлайн) для большей достоверности. Но при нескольких сотнях клиентов - равномерного распределения юзеров по каналам будет достаточно ИМХО. А работающего абона перекидывать с одного айпи ната на другой - как по мне, некошерно. Очень некошерно. Геймеры за такое тонны кирпичей на форумах вывалят - вовек не отмыться...

ip-down - удление правила из таблички, ip-up - добавление правила в ту табличку, где меньше всего записей...

Рилей можно на той же машине поднять... http://www.strongsec.com/freeswan/dhcprelay/index.htm к примеру (у нас 0.3.1 юзается, на промежуточных роутерах).

Циски 3550 хороши но жрут и шумят. 3750 - подороже, но с сфп вместо гбиков и вроде как ткам побольше (можно украину и дефолт на мир принимать). Можно поставить вообще тазики (какой-то целерон lga1155/lga1150 с i82571/i82576 спокойно несколько гбит пережует), + embedded дистр на SATA DOM накатить (LEAF к примеру - мы его пользуем) - работать будет долго и счастливо при грамотно подобранных компонентах и нормальном БП (FSP хотя бы). У нас аптайм тазиков обычно ограничен плановыми обновлениями и проблемами с питанием.

arp таблички переполнились и старые записи стираются? (предположение, хз как оно в бзде). И да, ушел с isc-dhcpd на перловый дхцп (проект на наге в софте висит), не нарадуюсь

Ну а чего парится тогда?

Ну да. Настройки мускула править если что (если кажется что памяти сильно много зря пропадает).

Память под кеш выделяется сразу фиксированным куском ЕМНИП...

Дык данные при коммите не ложатся в таблицу сразу же. Они ложатся в лог. И память. А потом, по мере наполнения лога/принятия мускулом решения что стоит сбросить накопившийся пакет данных в таблицы - тогда уже ложатся в таблицы на диске, с пересчетом ключей и т.п. То же самое происходит и при старте покрашившегося мускула. Ну да, там коммит в привычном понимании происходит после каждого запроса update/insert/delete. С "целостностью, индексами, внешними ключами"....

Ну в общем-то все не так и страшно, если кеш в памяти достаточно большой и большие лог-файлы (порядка часового объема записанных данных) - производительность весьма неплоха. Да, операция пишется сразу же в лог, но из лога в БД она попадает не сразу, а после группировки пачки изменений в транзакцию. В отличие от MyISAM. Итого - получается шустрее (MyISAM вроде как после каждого коммита же переписывает и индексы, т.е. - много iops мелкими блоками).

ib_logfile - журнал того, что не успело внестись в таблицы. Т.е. сначала попадает в журнал, потом - записи группируются и пишутся в базу. Советую потюнить базу (как - почитать на примере заббикса), реально на порядок увеличить кол-во записей в секунду. И да, innodb после тюнинга намного быстрее myisam. А главное - поддерживает транзакции и прочие плюшки.

Прекрасно получается. Варианты: 1) Включить стандартный ата контроллер 2) Пользовать акронисовую фишку замены драйвера 3) Заюзать sysprep 4) Ручками включить нужный драйвер в реестре после разворачивания, с лайв сд 5) В образе задействовать uniata драйвер

Поможет. Если не прятать лампочки далеко, и поглядывать на них регулярно.

Нам так не везло. Кабель проходит над рынком, со столба на 9-этажку. Рынок пару раз горел за последние несколько лет, а с ним и кабель...

Батареи вскрыть, долить дистиллята (пока матики не станут немного влажными), погонять каждую отдельно заряд-разряд (засечь время разряда на эталонной нагрузке через упс к приеру). Может еще поживут...

MSTP - если нужна различная топология для разных вланов. RSTP прекрасно управляется с кучей вланов если нет нужды иметь для разных групп вланов разнуб тпологию (т.е. форвардинг на порту гасится для всех вланов, а не для части их). ТСу MSTP особо не уперся. Но да, без поддержки аплинка - ничего не получится. Тут только костыли лепить, по SNMP портами/вланами на них рулить...

Там вроде шла речь про контроллер с постоянно включенным Ethernet портом. Под словом "контроллер" подразумевалось некое устройство мониторинга на двух платах в бескорпусном исполнении: http://local.com.ua/forum/topic/54568-тестер-наличия-электросети/#entry503567 Он что, умеет уходить в спячку при понижении U питания до 10,5В? И умеет потом просыпаться (кстати, при каких условиях)? А это вы у автора спрашивайте. Как он реализовал

25 серферов делают меньше нагрузку чем 1 торрент... Ну и да, еще, в голом роутинге без ната целерон 600 (на 66-й шине) на реалтек сетевушках в сумме более 200 мбит жевал легко. Правда, проц был в полку. Целерон/пенек нетбёрст не советую в основном из-за потребления. Как, впрочем, и К7 от амд. У К8-х с этим все стало ну просто замечательно. В простое семпрон 3000 останавливает кулер, при этом температура камня не превышает градусов 40-45... Под нагрузкой - жрет Вт 50-70 весь тазик в сумме. Ну и да, целеронов 800 с ддр1 нет в природе (ну если не считать экзотику типа PLE266 толку от ко

Выкиньте, поставьте какой-то семпрон сокет 754. Ну или атом/целерон новый. Хотя все равно маловато будет, у меня домашний тазик на целероне 800 лопатил легко мегабит 80-100+ в сумме...

Если сделано все правильно (LDO с малым током потребления, sleep на МК, гашение питания периферии/увод ее в спячку) - это "некоторое время" будет исчисляться месяцами. Ибо ток потребления будет менее миллиампера.

По поводу скрутки корпусов: мы себе под девайсы заказывали корпуса несколько лет назад - для нарезки резьбы нам там проштамповали отверстия 2.5-2.7мм (с заворотом металла вовнутрь - похоже, внутреннее отверстие второй части штампа было миллиметров 5-6 диаметром), в этом отверстии метчик на 3 прекрасно нарезает резьбу... Дешево и сердито.