Большие потоки трафика и управление прерываниями в Linux

вообще прерывания неплохо автоматом раскидываются таким скриптиком

ncpus=`grep -ciw ^processor /proc/cpuinfo`
test "$ncpus" -gt 1 || exit 1

n=0
for irq in `cat /proc/interrupts | grep eth | awk '{print $1}' | sed s/\://g`
do
    f="/proc/irq/$irq/smp_affinity"
    test -r "$f" || continue
    cpu=$[$ncpus - ($n % $ncpus) - 1]
    if [ $cpu -ge 0 ]
            then
                mask=`printf %x $[2 ** $cpu]`
                echo "Assign SMP affinity: eth$n, irq $irq, cpu $cpu, mask 0x$mask"
                echo "$mask" > "$f"
                let n+=1
    fi
done

Большие потоки трафика и управление прерываниями в Linux

если нет необходимости в conntrack его тоже надо отрубить
*raw
-A PREROUTING -j NOTRACK
COMMIT

увеличить очередь
ifconfig eth0 txqueuelen 10000

потом смотреть ошибки и по необходимости увеличить буфер
ethtool -G eth0 rx 1024

если надо conntrack то увеличивать
net.ipv4.netfilter.ip_conntrack_max и /sys/module/ip_conntrack/parameters/hashsize
и уменьшать интервалы
net.ipv4.netfilter.ip_conntrack_icmp_timeout
net.ipv4.netfilter.ip_conntrack_udp_timeout_stream
net.ipv4.netfilter.ip_conntrack_udp_timeout
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait
net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent

уменьшать количество правил iptables, если надо много однотипных списков то использовать ipset

и пр. пр. пр.

Серверный редирект на мобильную версию сайта

Спасибо, то что нужно

Вышел релиз Red Hat Enterprise Linux 6

ИМХО: К сожалению CentOS 6 месяца через 2 только выйдет.

Стоит ли гоняться за тремя копейками, когда под ногами лежит рубль?

Правильно я понял, что основная мысль статьи состоит в том, что: Работать много за малые деньги — плохо. Работать мало за большие деньги — хорошо.

Тогда предлагаю еще одну свежую идею: Не работать — за огромные деньги.

Ручная сборка PostgreSQL для 1C 8.2, или легкие пути не для нас!

Прошу пардона, не имел цели Вас оскорбить.

>Я понял типаж, который Вы имели в виду. Извините, не наш случай.

Радует.

Ручная сборка PostgreSQL для 1C 8.2, или легкие пути не для нас!

я об этом v8.1c.ru/overview/postgresql_patches/8-4-1/postgresql-8.4.1-1.1C.src.rpm
Рекомендованная 1c версия PostgreSQL под Linux. Кривая или нет, это совсем не тот вопрос. Вопрос в том поддерживаемая или нет.

Насчет сапорта ради интереса попробуйте обратиться в сапорт 1c с вопросом «я тут пересобрал PostgreSQL из сорцов с вашими патчами под МОЙ_ЛЮБИМЫЙ_ДИСТРИБУТИВ и у меня не работает» и будете крайне удивлены.

Ручная сборка PostgreSQL для 1C 8.2, или легкие пути не для нас!

Не спорю, автор стал обладателем уникальных знаний, но проблема в том, что он нигде не сможет ими воспользоваться — такими вещами НИКТО в продакшн заниматься не станет, ибо любой сбой может обернуться не кислыми проблемами за которые понесет ответственность наш дорогой litnimax.

Или если переходить на аналогии, то его уникальные знания, это как член длинною в метр — очень круто, но абсолютно бесполезно.

Ручная сборка PostgreSQL для 1C 8.2, или легкие пути не для нас!

Я так понимаю, что за все эксперименты заплатил Ваш работодатель?

Немного поясню свою мысль.

Производитель ПО выложил протестированные и готовые к использованию пакеты для определенной ОС, производитель дает гарантии работоспособности и поддержки в случае если используется только данная ОС.

Вы Вместо того чтобы выбрать инструмент исходя из потребностей выбираете совершенно другой инструмент исходя из собственных предпочтений, мучаетесь неделю или две стараясь заставить его работать.

Внимание вопрос в курсе ли работодатель что вы просто «украли» у него две недели Вашего рабочего времени?

В курсе ли работодатель, что Вы сделали костыль гарантии работоспособности которого не даст никто?

Все больше утверждаюсь в мысли, что существует класс людей обладающих определенными знаниями, но которых надо принудительно изолировать и не давать возможности пользоваться данными знаниями — так как они дискредитируют и портят имидж своей профессии.

Linux на службе у провайдера

Аналогично, посмотрели на 5505 — нормально работала, посчитали сколько будет стоить парочка 5580 которые «пройдут» по трафику и желание покупать пропало — за эти деньги можно новый самолет купить.

Linux на службе у провайдера

Если не затруднит, то модель сетевой и драйвера (подозреваю, что igb ?)

Linux на службе у провайдера

Да как бы и мы «выросли» и теперь используем оборудование от самых извесных вендоров, просто в определенные моменты роста «домового» провайдера есть смысл применить более дешевые решения а на съэкономленные деньги развивать инфраструктуру и быстрее захватить часть рынка, чем вложиться в более дорогое железо и «сосать лапу».

Данная статья как Вы могли заметить подводит некоторую черту, так сказать «подитоживает» наш опыт использования программных решений.

Спасибо за комментарий, спите спокойно :)

Linux на службе у провайдера

Вполне очевидно, что когда пользователь работает из-за NAT, то его компьютер не виден напрямую, т. е. косвенно повышается безопасность клиента, от некоторых видов сетевых атак, например у атакующего нет возможности прямо просканировать открытые порты на компьютере клиента.

Если бы мы выдавали «живые» ip то любой флуд на ip клиента занимал бы его полосу, т. к. полосы в те далекие времена были «узкими» а анлим дорогим, то мы приняли решение помочь клиентам. Для тех из клиентов кому был необходим «белый» ip такая услуга безусловна предоставлялась.

Linux на службе у провайдера

Постепенно, Потихоньку, Помаленьку (ППП) ушли в сторону аппаратных решений от вендоров указанных в начале статьи.

Linux на службе у провайдера

Выдавали пользователям /30 сетки, причем с самом начале еще и отдельный VLAN на пользователя.

Недостатки такого подхода всплыли очень быстро :)

Бэкапы для трусов!

Вы вокруг пальца, линк на «серый» а память жарят на «зеленом»

Пишем свой драйвер под Linux

Спасибо, Вам стоит задуматься над идеей написания «Linux Kernel for Dummies» :)

Linux Mint 10 Julia в предвыпускной стадии

Простите за бестактность, но на чьи деньги развивается дистрибутив?

Несколько страшновато пересаживать на «темную лошадку» как сервера так и рабочие станции не зная например времени поддержки дистрибутива.

И дежурный вопрос «Обои там новые? » :)

Два подхода к тестированию производительности. Выбираем

Если говорить о сферическом проекте в вакууме, то вполне верным будет Ваше утверждение, что вертикальное масштабирование ограничено текущим технологическим потолком.

Капитан спасибо Вам, что открыли мне глаза :)

Два подхода к тестированию производительности. Выбираем

В статье написано, что ресурс в том виде, котором окончилось его развитие состоял всего из трех серверов.

Тем более используется простейшая схема распределения ролей по серверам:

1. nginx
2. php-fpm
3. mysql

куда можно было бы расти дальше на мой взгляд вполне очевидно.