KaYot

Ну с зарядкой за час rsst явно немного преувеличил, или там нагрузка в разы меньше, или просто УПС не показывает процесс заряда нормально.

Слушай, лучше уж быть недалеким пионером, чем тупым электриком. Как говорит мой жизненный опыт - в сутках таки 24 часа. И при отключениях на 2-4 часа остается примерно 20 часов на заряд. Или тебе надо обязательно за час зарядить автомобильным бустером с брызгами электролита по какой-то фантастической схеме?

Вместо этого анонизма куда проще поставить нормальный УПС, который будет успевать заряжать. Китайцы рассчитанные на подключение внешних батарей имеют зарядник в 10А и замечательно заряжают 150а/ч поросенков в перерывах между отключениями. Если уж отключения более 5-6 часов в сутки - помогайте геной.

Может он не такой злой как ты?)

А что с 3550 не так? Память заканчивается? "Недорогих" под принятие современного ua-ix нет, нужно 16к+ маршрутов. Сейчас один из магистралов мне наливает 15832 префиксов, а значит и 16к уже не особо канает. Могу порекомендовать cisco WS-C4948 и WS-C4948-10GE с 32к маршрутов. Стоит 4948-10GE у нас, работает идеально, денег на ебее стоит $1к. Без 10G еще на пару сотен меньше.

ring buffer поднимал до 1024-2048? Отключай intel_idle, вероятно дело в нем.

Не, полностью энергосбережение выключать нет смысла. Параметрами ядра задается глубина сна С1 и пусть себе отдыхает в halt'e, без каких-либо накладных расходов.

Я раскидаю прерывания без перегрузки модуля. Я про включение/отключение очередей. Без очередей потерь нет, с очередями есть, я правильно понимаю?

Тогда беда где-то совсем в другом месте. Ошибки даваемые сетевкой из-за аппаратных глюков/патчкордов/нехватки буферов/перегрузки прерываниями и т.п. видны в статистике ethtool. Может банально бонд разваливается после перегрузки модуля?))

Добавь параметры ядра при загрузке системы intel_idle.max_cstate=0 processor.max_cstate=1 - рекомендуемые от hp/intel.

Покажи ethtool -S eth0 | grep error Что за ошибки хоть идут? Ну и можно попробовать с другой стороны подойти. Оффлоады выключены? Может банально шейпер глючит? ethtool -K eth0 gro off gso off tso off

Частота должна быть стабильной 2533(с учетом турбо), и в С0 система уходить не должна.

Да, номер ядра это core-id. И работают они у тебя сейчас вперемешку, в этой утилите удобно смотреть реальное состояние ядер/сокетов. И да, у тебя активно энергосбережение. И оно легко может быть источником всех бед. Убивай cpuidle и сервис cpuspeed.

Хехе. А ты уверен что ядра по сокетам раскиданы подряд? Лучше проверь скриптом типа этого http://pastebin.com/RS8e23jd или утилитой i7z.

Да я уже думал 8 вольтметров аналоговых прицепить и камеру направить. Такой себе мониторинг Или посоветуйте нормальное решение, с возможностью опроса 8 каналов по IP.

Я например очень хотел бы видеть реальное напряжение на каждой батарее. Ибо УПС показывает правду о процентах заряда только при идеальных(одинаковых) батареях, а даже небольшой разброс емкости ведет к ситуации "50%-40%-0% опп аварийно потухли", т.к. на одной батарее уже давно 9в. Но реализация этого видится куда сложнее самого балансира.. Реально сделать светодиод возле каждого канала, и пусть горит тот что выбивается по напряжению от среднего? Ну и еще один общий диод, показывающий что беда близко(низкое напряжение в любом из каналов).

Ты лучше ошибки смотри с помощью ethtool -s ethX(или -S, не помню). На этом поколении еще больших печалей с сокетами нет, контроллер pci-e чипсетный, разве что память на разных CPU. Когда тестировал 2х5560 в этом же сервере, минусов от раскидывания на второй сокет не было. В идеале сделать сетевки входящие в первый бонд на 1 сокете, во второй - на втором.

Вот такой же сервер с теми же сетевыми [root@ipoe1 ~]# top Cpu0 : 2.6%us, 5.3%sy, 0.0%ni, 61.6%id, 0.0%wa, 1.1%hi, 29.5%si, 0.0%st Cpu1 : 2.7%us, 3.2%sy, 0.0%ni, 64.0%id, 0.0%wa, 0.0%hi, 30.1%si, 0.0%st Cpu2 : 2.5%us, 2.0%sy, 0.0%ni, 58.4%id, 0.0%wa, 0.0%hi, 37.1%si, 0.0%st Cpu3 : 3.6%us, 2.1%sy, 0.0%ni, 52.8%id, 0.0%wa, 0.0%hi, 41.5%si, 0.0%st Cpu4 : 2.0%us, 4.1%sy, 0.0%ni, 61.2%id, 0.0%wa, 0.0%hi, 32.7%si, 0.0%st Cpu5 : 4.7%us, 2.1%sy, 0.0%ni, 60.7%id, 0.0%wa, 0.0%hi, 32.5%si, 0.0%st Mem: 6104752k total, 2669472k used, 3435280k free, 278068k

Попробуй раскидать жестко, руками, прописав соответствие очередь-ядро в /proc/irq. Не должно быть таких чудес, скорее всего скрипт раскидывает неверно и какое-то ядро в реальности забито на 100%.

Почему много? С 1.5Г НАТа же.

На этом сервере ж бортовой Ilo2 есть, в смысле пропадет?

Дык в modprobe options запихните и в ребут. Если клиентов не жалко

Нужны данные в момент глюков, с очередями и без HT. Размеры буферов меняются в онлайне без потери сервера, попробуйте для начала.

Ну если загрузка устраивает - так и оставьте. Но лучше включите очереди и увеличивайте ring buffer. Заодно можно и очереди отправки увеличить, хуже точно не будет. Весь мой "тюнинг": echo 10000 > /proc/sys/net/core/netdev_max_backlog ethtool -G eth0 rx 1024 ifconfig eth0 txqueuelen 10000 Карты нормальные, буфера большие, очереди умеют - что еще роутеру надо?

Не, карты нормальные, свой гиг пропускают гарантированно. Покажи top и proc/interrupts с включенными очередями и раскиданными прерываниями. Должно быть как-то так http://pastebin.com/ZJxciqPa (dl380 g6 с теми же картами, прерывания раскиданы "лесенкой" на 6 ядер). Еще покажите ethtool -g eth0 cat /proc/sys/net/core/netdev_max_backlog ifconfig eth0 | grep txqueuelen