NiTr0

Угу, наконец-то стадо, истосковавшееся по привычной сильной руке, обрело достойного пастуха Глядишь - и повторное открытие ГУЛАГа в близком будущем отпразднуют всеросийскими гуляниями

Клеевое соединение - сильно зависит как от качества обезжиривания поверхности, так и от качества/толщины слоя/силы прижима/досушенности термоклея. В целом - как по мне, защелки предпочтительнее при сколь-либо массивных радиаторах. Ну или хотя бы термоклея не жалеть - на всю поверхность наносить, а не пятно по центру. Если уроненное с высоты стола устройство приходит в нерабочее состояние из-за осыпания радиаторов - это не есть хорошо.

А проверить перед заменой - некошерно? Тестер, источник 12В (или сколько там)...

Я бы махнул реле, а не копался с контактами. Там еще скорее всего какой-то инертный газ внутри, т.е. - работать после будет несколько хуже/меньше...

Есть еще и рэйдовые винты (вроде как несколько лучше в многопоточных операциях), есть еще и винты кроме вд... Зеленые - 5400 об/мин, скорость случайного доступа эдак 12-15 мс... Еще и головы паркуют...

К слову, у китайцев есть дешевые датчики влажности, скрестить его с какой-то малинкой или вообще на демоборде с стм32 слепить девайс с эзернетом... Помониторить, потом - думать. Хотя как вариант - гермобокс.

Ну так правильно. Время доступа зависит в основном от скорости вращения (ну и еще от настроек ААМ). Что 10 лет назад, что сейчас, время случайного доступа примерно одинаково.

Отрисуйте схему, проверьте работу реле, проверьте прохождение управляющего сигнала к реле...

"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 заюзать - вроде как суть то же), смерть ssd к катастрофе не приведет...

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

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 драйвер

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