Потом просто find ./ -name "*.bak" -delete
или другое окончание которое невстретиться в системе, типа .875ygth974 (только в sed запросе -i сменить его не забудьте)
Пускай паники сделают скрин и то хлеб. У нас обнаруживались ошибки в igb.
Feb 24 03:01:29 cl1123 kernel: interrupt storm detected on «irq16:»; throttling interrupt source
Feb 26 03:00:38 cl1123 kernel: mfi0: 8252 (352004400s/0x0020/info) — Patrol Read started
Feb 26 03:00:38 cl1123 kernel: mfi0: 8253 (352004400s/0x0001/info) — Consistency Check started on VD 00/0
Feb 26 03:00:38 cl1123 kernel: mfi0: 8254 (352004400s/0x0020/info) — Patrol Read complete
Feb 26 04:49:28 cl1123 kernel: mfi0: 8587 (352010929s/0x0001/info) — Consistency Check done on VD 00/0
Feb 27 03:06:29 cl1123 kernel: interrupt storm detected on «irq16:»; throttling interrupt source
Feb 27 20:50:29 cl1123 kernel: interrupt storm detected on «irq16:»; throttling interrupt source
irq16 это как раз райд — mfi0.
Нагрузки на него 0.0 ибо пишется один файл.
И да, кажется это судьба «первой» линейки 56хх платформ. IBM с таким же драйвером райда вроде не штормите. Но при нагрузке не процессор начинает глючить также.
Sun с 55хх и носом не ведет, все отлично работает.
Может еще что замечу скажу. Например от local_client.send(gate_client.recv(4096)) # BUG HERE, in recv тут действительно баг
должно быть что-то вроде
data = gate_client.recv(4096)
if not data:
break
local_client.sendall(data)
Да и верхний recv тоже не верен (тот который от local_client), вдруг данных будет > чем 4096? сокет будет писать, а Вы пошлете ему данные — непорядочек…
Во-первых, send используется в loop типа
m = 0
while m < len(object):
m = sock.send(object[m:])
или что-то вроде того (можно буфер object уменьшать, если с памятью проблема — но нагрузка на проц тогда)
или использовать sendall()
во-вторых, у Вас прописан HTTP/1.1 а Connection: close нет — может вызывать баги при коннекте.
в-третьих Вы посылаете на 4 байта больше, чем прописываете в Content-length (\r\n\r\n в конце)
Без проблем, удачи Вам!
Вместо того, чтобы плодить nginx на всех серверах посмотрите в сторону haproxy — он поддерживает tcp splicing на уровне ядра в linux, может и 10 гбит/с раздачей статики забить на Core2 сервере не самой крутой комплекции. Даже на FreeBSD он больше впечатляет нежели nginx, единственное но — haproxy — это PROXY сервер только, но на LB в случае такого масштабирования самое то (он используется и в коммерческих железячных LB). (просто следует использовать правильный инструмент для своего дела haproxy как прокси без ssl незаменим, в случае ssl конечно лучше nginx, т.к. все в одной коробке)
Если будет нужно что-то особенное в Европе, обращайтесь :).
Да, только внимательно смотрите, что берете. У меня есть факты даже разной работы двух одинаковых сетевых карт, но от Intel и от Sun (чипсет тот же — igb). На Intel они вылетают под большой нагрузкой, на Sun проблем не было ни разу никаких с системами, что я перечислил.
Вам я советую ставить ОС с которой Вы лучше всего знакомы. Для меня просто FreeBSD это инструмент больше, все закавыки которого я знаю очень хорошо. Например с виртуализацией там довольно-таки хреново. Из Linux мне больше импонирует Debian.
И помните, 250 000 000 хитов в день это всего лишь 413 хитов в секунду, что довольно низкая нагрузка на самом деле, если смотреть не на среднюю, то будет что-то вроде 1250 в пики и 200 в 4 утра, что опять же мелочь.
Во FreeBSD придется следить за mbufs,, ошибками на интерфейсе (т.к. железо может быть плохим по качеству и не выдерживать).
И пару настроек ядра в /boot/loader.conf, еще придется добавить кое-что в sysctl.
С CentOS мое знакомство было кратким и неблагоприятным, поэтому не могу сказать, во FreeBSD подобные вопросы решаются просто и хоть 1млн онлайн, главное чтобы памяти было достаточно (не помню соотношения для буферов уже к сожалению) и платформа железная крепкая и слаженная (второй или третьей ревизии, у нас для это Sun Fire x4150-4170 стоят, IBM x3550M3 был не лучшим выбором, т.к. сыровато железо, как и у Intel последней архитектуры).
Считать можно по логам, логи писать nginx кастомные умеет. Можно даже в реалтайме считать, если разобраться с модулем сислога nginx и поставить syslog-ng3.
Возможно все. Я думаю Вы врядли с баннерами упретесь во что-нибудь кроме производительности сетевой карты и корректности железа и дров для них.
Для примера: сервер, если считать по ночным часам, обслуживает в среднем 8672344 хитов в день (считал только ответ 200 для зипов и картинок, 304 и т.п. не считал), nginx этого даже не замечает (FreeBSD 8.1 оттюнингованная), нагрузка nginx 0.00%-1.75% процентов максимум (и то в пики). Система конечно IBM. Но процессор и в африке процессор, поэтому E5630 вообще не нагружен. Уверен другие системы тоже не заметят.
или другое окончание которое невстретиться в системе, типа .875ygth974 (только в sed запросе -i сменить его не забудьте)