SaveTheRbtz
+3

Ну, если совсем по чесноку, то не все =)


На больших нагрузках nginx может блокировать eventloop на:


  • Записи логов. В случае access_log'ов — может сильно помочь директива buffer=. Однако в идеале лучше писать логи напрямую в syslog.
  • Записи тел запросов и ответов на диск. Тут хорошо помогает костыль в виде aio threads. Однако, насколько я понимаю, он не работает для приёма файлов, только на отдачу.
    (Почему костыль? Потому что в идеале aio должно работать через нативный аснихронный интерфейс к файловой системе, а не эмулироваться через thread pool, но в *nix ОС с этим всё плохо).
  • В худшем случае, nginx начинает блокироваться на TLS хендшейках: если вы используете RSA 2048 это примерно 2мс на handshake. В новом OpenSSL 1.1.0 появилось асинхронное API, но в nginx оно если и попадёт, то не скоро. (Патчи по интернетам ходят, но до продакшна я бы их не допускал пока).
  • Были ещё сложные случаи со сжатием, когда люди пытаются максимально сжать статику (например, gzip 9 и brotli 11). в таких случаях сильно лучше статику pre-сжимать в офлайне и использовать gzip_static и brotli_static. Что делать если хочется по-максимуму сжимать динамку пока не понятно, но оно обычно того не стоит. (Можно, наверное, сжимать на backend'е(или маленьком sidecar-демоне), но это значит больше нельзя применять никакие body-filter'ы).
  • Image Filter'ы скорее всего тоже могут блокировать eventloop, но я, если честно, код не смотрел, ибо не использовал — все конторы в которых я работал писали простенькие backend'ы для "тяжёлых" манипуляций типа resize/recompress/crop/etc.
SaveTheRbtz
+1

Проблема лишь в том, что маленький ssl_buffer_size добавляет измеримый CPU-overhead. И если есть желание оптимизировать один и тот же конфиг для пропускной способности и низкой задержки, то необходимо вручную выставлять нужный размер буферов для каждого server/location блока в зависимости от гистограммы размеров ответов.

SaveTheRbtz
+8
Дамп сознания.
  • На CentOS/RHEL лучше тащить своё ядро из последних (3.16+, а то и 4.x, если есть лица способные чинить panic'и/регрессии)
  • При возможности ещё и собирать последние ixgbe/i40e от интела (ну или хотя бы README прочитать — он весьма полезен) и последний ethtool
  • Последняя версия set_irq_affinity.sh из того же комплекта — must have
  • Не забывайте, что irq affinity можно навешивать не только на сетевухи, но и на storage девайсы
  • Новые сетевухи умеют `adaptive-rx`/`adaptive-tx`, совсем новые `rx-usecs-high`
  • NUMA лучше не interleave'ить, а использовать по назначению. Запустите N инстансов приложения. Каждое на своей ноде. Каждой свой CPU и память, а так же сетевуху (NUMA ноду для irq affinity через можно определить от /sys/class/net/eth*/device/numa_node) и свой набор IP'шников. Далее на вышестоящем балансере (я так пологаю IPVS) считать каждую NUMA-ноду за отдельный хост
  • Для файлсерверов очень опасна /proc/sys/vm/zone_reclaim_mode — важно, чтобы оно было выставленно в ноль
  • Flow Director может приводить к сильному реордеингу. Наступали на это в кеше в Facebook'а.
  • Не забываем играться со всей магией из ethtool -k (tso, lro,[rt]xcsum, etc) и почти всегда надо задирать ring buffer'а в ethtool -g
  • Обратите внимание на топологию PCIe и скорость: lspci -t -vvv (особо важно для 40G+)
  • Проверить, что ioatdma/DCA включено и работает
  • Всё что выходит за пределы 40G — надо переходить на Netmap/DPDK/etc
  • Jumboframes наружу конечно нельзя, но вот внутри сети лучше включить
  • Если у вас есть HTTPS, то всё становится сложнее, Netflix опять же похачил (FreeBSD'шное) ядро, чтобы то умело делать sendfile(2) с AES
  • Уже не совсем в тему оптимизации производительности, а скорее ускореения пользователей — стоит поиграться с TCP congestion алгоритмами (Netflix написали свой оптимизированый для видео и их склиентов: cc_netflix) — щас говорят ещё модно CDG (упаковать его в dkms и проверить на паре фронтэндов займёт пол дня)
  • Если бы у вас были интерактивные штуки, а не видео, то было бы интересно поиграться с buffer bloat (sch_fq, tsq, bql, etc).
  • В ту же степь: net.ipv4.tcp_slow_start_after_idle=0
  • В userspace (оптимизация webserver'а) можно быстро получить выхлоп от нового OpenSSL 1.0.2 и Haswell (там переписан TLS RSA handshake на AVX2)
  • Новый pcre с jit (или замена его на re2)
  • glibc malloc (почти ptmalloc) заменить на jemalloc
SaveTheRbtz
0
Начиная с 3.5 в ядре Linux появились uprobe'ы, то есть фактически аналог kprobe для userspace'а. Они тоже местами весьма полезны:
Пример использования uprobe с perf
# perf probe -x /bin/bash 'readline%return +0($retval):string'
Added new event:
  probe_bash:readline  (on readline%return in /bin/bash with +0($retval):string)

You can now use it in all perf tools, such as:

    perf record -e probe_bash:readline -aR sleep 1

# perf record -e probe_bash:readline -a
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.259 MB perf.data (2 samples) ]

# perf script
 bash 26239 [003] 283194.152199: probe_bash:readline: (48db60 <- 41e876) arg1="ls -l"
 bash 26239 [003] 283195.016155: probe_bash:readline: (48db60 <- 41e876) arg1="date"
# perf probe --del probe_bash:readline
Removed event: probe_bash:readline


SaveTheRbtz
0
Из доступных рядовому юзеру кросс-платформенных open-source'ных torrent-клиентов сейчас есть, как минимум, transmission — при особом желаннии провайдеры/трекеры могут начать продвигать свои BEP'ы и контрибьютить код в апстрим.
SaveTheRbtz
+4
Bitcoin в качестве proof-of-work использует количество правильно про-brute-force'иных бит sha256 хеша. То есть, жжошь CPU — получаешь деньги «из воздуха». Если придумать как делать proof-of-work на основе сремени хранения данных на диске, то можно построить экономическую систему, где новая валюта получаются путём генерации востребованного контента, а существующая получается через/тратится через скачивание/раздачу контента и аренду места/полосы у других участников сети под свои данные (тут можно замутить аукцион). Опять же, как описать всё это математически и защитить цифровыми подписями — отдельный вопрос

Фактически, всё вышеописанное, это ровно то как сейчас работают трекеры, где в качестве валюты используется «ratio» (которое отражает сколько раздач и как долго ты хранишь). Всё централизовано и в качестве регулятора валюты выстурает трекер. Разве, что в торренте нет способа пропросить кого-либо хранить и раздавать твои данные в обмен на свой ratio.
Отдельный вопрос как анонимизировать всё это. В bitcoin вся история транзакций публична, что может сильно усложнить дальнейшую «анонимизацию» пользователей такой bitcoin-style p2p системы.

В общем, дискуссия про то как скрестить p2p и bitcoin вполне потянет докторскую. Тема интересная, да.
SaveTheRbtz
+3
В далёком 2007 году, когда мало кто мог представить, какая цензура будет грозить российскому интернету, мы в NNM-Club обсуждали альтернативы bittorrent'у:
Share & WinNY: японские p2p

Что самое интересное все три сети Winny, Share и Perfect Dark родом из японии, где шарить в сети аниме весьма распространённое и довольно опасное занятие.
Ещё в последнее время сильно набрал популярность Freenet.

Данные сети частично используют идеи из этого поста, частично из I2P/tor, частично из bittorrent. Но в любом случае все они сильно отличаются от того, что мы на данный момент имеем в мире торрент-трекеров. Думаю преминив некоторое кол-во усилий можно написать «прокси» из bittorrent в анонимные сети (например, freenet) и сделать его плагином к торрент-клиентам, чтобы то, что было скчано/роздано через bittorrent автоматом клалось и туда. Посути такой dual-stack получится (прям как во время перехода с IPv4 на IPv6). Я делал что-то подобное когда использовал Direct Connect и Bittorrent: то что у меня скачивалось rtorrent'ом автоматически шарилось в DC++.
SaveTheRbtz
+1
А что если количество «расшареных» байт места помноженых на кол-во отданных байт можно принять за валюту? Тогда на неё можно будет «покупать» место и канал на других компьютерах сети.

Тут возникает проблема, что самыми богатыми будут люди с кучей места заполненым популярным контентом, но тут можно что-то придумать с приоретизацией редкого контента.
SaveTheRbtz
+1
DHT в то время часто отключали(помечали торренты «private» битом на upload'е), чтобы траффик не уходил «налево», тогда, например, проще отлавиливать читеров, да и прирост постетителей выше.
В итоге кажмоу конкретному сайту отключать DHT/PEX/LPD выгодно, но в общем файлообменной сети это вредит.
SaveTheRbtz
–27
Если человек в наушниках или с книгой, то да — спамите.
SaveTheRbtz
–29
На хабре есть замечательный раздел Q&A, если вы хотели узнать мнение хабравчан, то стоило спрашивать там, а не пассылать 25*2 одинаковых сообщений незнакомым людям.
SaveTheRbtz
–73
Я просто оставлю это здесть:

DaryaZ, вчера в 16:12
Здравствуйте! Хотела бы получить ваш совет.
У нас есть очень интересная статья с интересным гостем. «Темный игрок рынка» рассказывает про «темны» методы монетизация трафика, и реально раскрывает многие схемы, на которые ведется даже PR отдел Mail.ru
Вот статья: docs.google.com/document/d/1vcqLKP57fQsmg6zaa0LC6wAaDZHV8qAmPPc35yG1E2s/edit
Я очень хочу рассказать Хабра сообществу об этом, но… Я не знаю как сделать, чтобы этот пост набрал нужное кол-во лайков чтобы стал распространяться по Хабре.
Каким сделать начало поста? До Habrbacut? Как заинтересовать читателей?

DaryaZ, сегодня в 00:52
Опубликовала: habrahabr.ru/company/apps4all/blog/225409/
Но меня минусуют :( Блин, весь день писала :(
Скажите, как вам статья? (Только плиииз не минусуйте)

SaveTheRbtz, сегодня в 00:57
О! Спасибо за сылку! Не читал, но заминусовал.
ПС. На хабре не любят спам, особенно в ЛС. Имейте совесть — не тратьте время людей.

DaryaZ, сегодня в 00:58
Почему же спам? Вы входите в 25 лучших в хабра рейтинге, вот я вам и написала посоветоваться

SaveTheRbtz
+1
Так же хочу заметить, что если уж шифровать данные, то стоит делать это надёжно, явно указывая алгоритм, размер ключа и mode-of-operation, например, AES256-XTS:

% geli init -l 256 -e AES-XTS
Бенчмарки тут: forums.freebsd.org/showthread.php?t=31425 (в случае AES-CBC ядрёный aesni.ko помогает удваивая скорость шифрования)

Для особо параноиков которые хотят ещё, чтобы их данными нельзя было манипулировать можно включить аутентификацию данных с помощью, например, HMAC/SHA256: -a HMAC/SHA256, что добавит уверенности в читаемых данных, но сократит кол-во места на диске и слегка замедлит его.

Ну и в завершение крайне рекомендую почитать man geli там ещё много всяких интересностей:
SaveTheRbtz
0
Из минусов только то, что в случае краха coredump на такой swap раздел писать бессмысленно.
SaveTheRbtz
0
Я шефом не пользуюсь уже довольно давно, так что мои знания относительно Best-practice'ов довольно сильно устарели, я пожалуй отправлю вас к более компетентным людям и пользуясь случаем пропиарю русскоязычную Google Группу: groups.google.com/group/devopsru — попробуйте задать вопрос там — вам наверняка оперативно и развёрнуто ответят.

Также думаю вам могут быть интересны:
Google.Hangouts: HangOps_ru
IRC: FreeNode /j #hangops_ru
Там можно найти множество интересных идей.
SaveTheRbtz
0
Tagged pointer используется в Linux'овой реализации rb-деревьев для хранения цвета прямо в младшем бите pointer'а на parent'а.
SaveTheRbtz
0
Часто слушаю лекции по программированию от Stanford / MIT / Berkeley / etc на iTunes U / MITx — в этих вузах всё примерно так и устроено.
Где свою ОС пишут, где чужую улучшают, где-то ещё полезности в опенсорс кладут.

У нас в ВУЗе (привет ИТМО!) была скукатень. Одни и те же лекции / лабы / экзамены из года в год. Design doc'и не писали, SCM не использовали, лабы сдавали на бумаге, как, впрочем, и экзамен. Студенты с потока если, что и делали интересного, то делали это в свободное от учёбы время =/
SaveTheRbtz
+9
С первых строчек статьи стало понятно, что первый комментарий будет про Chef/puppet
SaveTheRbtz
+1
Подумайте о следующем админе вашей конторы — ему же, бедняге, во всём этом разбираться придётся!
SaveTheRbtz
+6
И это в плюсе?! Ужс.

Приемы написания скриптов в Bash

Собственно, конкретно bash'а я тут и не увидел(впрочем, код смотрел по диагонали).
Вы вдруг нажали не на тот скрипт, то с системой может произойти все что угодно.

Вы работаете под рутом?
Ты уверен, что хочешь запустить это (y/[a])

Собственно к каждому скрипту надо делать usage(), а не эту хрень спрашивающую почём зря неадекватные вопросы. Как вы этот скрипт будете запускать на 100 серверов? Писать второй на expect?
В Bash не очень хорошо обстоят дела с возвратом значения из функции

Использовать глобальную переменную для этого плохо, ибо тогда их нужно создавать по одной на каждую функцию. Обычно вместо этого используют printf или передачу имени переменной назначения через параметр + eval.

Автору: сходи-ка ты почитай хороший sh, например, svn.freebsd.org/base/head/etc/rc.subr
SaveTheRbtz
+1
Хорошая статья, тут можно разве, что пропиарить книжку: SSH Mastery: OpenSSH, PuTTY, Tunnels and Keys

Ну и пара «интересностей» ещё:
1. ControlMaster — уже упомянули пару раз в комментах.
2. Извлечение public ключа из private: ssh-keygen -y -f id_rsa > id_rsa.pub
3. pam-ssh-agent-auth тоже интересная штука, особенно в комбинации с вышеописанным authorized_keys2
4. ssh-keyscan бывает полезна, впрочем любители chef/puppet/cfengine могут собирать ключики с машин более эффективным образом.
5. В последних версиях OpenSSH начали использовать Elliptic Curve DSA
SaveTheRbtz
0
Дайте угадаю — у вас rtt до сервера в районе нескольких секунд? А теперь представьте, что сервер в Америке? Опять же ждать пока разгонится slow-start на LFP при передаче файлов не очень хочется.

Засирание логов действительно не важно, пока «безопасники» не начинают жаловаться (у некоторых компаний так вообще IDS лицензируются по кол-ву обрабатываемых сообщений). Да и самому приятнее потом в чистых логах разбираться, если нужно будет.
SaveTheRbtz
0
ИМХО, с помощью Python нужно собирать/парсить данные и генерировать графы в одном из общепринятых форматов, а анализировать результаты удобнее в Gephi
SaveTheRbtz
0
Любителям по-разбирать кастомные грамматики на Python стоит посмотреть на PLY by David Beazley
SaveTheRbtz
0
Даня, это шикарно!
SaveTheRbtz
0
Не пробовал, не читал, но осуждаю (с)
SaveTheRbtz
0
Hardware очередей на igb сейчас 8. Это значит будь у вас хоть 1024 ядра до RPS/RFS дело не дойдёт, если сетевуха не сможет переварить столько пакетов.
SaveTheRbtz
0
У нас igbшная сетевуха выдерживает без тюнинга 275к пакетов. С тюнингом и бондом на 2 гигабита до 1кк. Ядер много не надо, я вообще не видел дров которые нормально распараллеливаются на больше чем 8 потоков.

Вообще интересно узнать подробнее про специфику этого ддоса:
1) TCP/UDP.
2) Медиана размера пакета
3) Примерный размер вектора аттаки

А то в нас последнее время тож зачастили пуляцца.
SaveTheRbtz
0
Вот что получилось, если вдруг кому интересно:

SaveTheRbtz
0
Очень вовремя, как раз хотел с помощью Gephi нарисовать граф взаимодействий наших поисковых серверов. Спасибо!
SaveTheRbtz
0
Учитывая, что больших файлов у нас не водится, writing очень хорошо коррелирует с тормозами backend'а. Вообще, когда мы разбирались в проблеме мы строили графы на основе php-fpm-slow.log'а — там всё было как на ладони.
SaveTheRbtz
0
Может быть научить кеш общаться с какой-нить очередью и при протухании кеша добавлять туда job?
SaveTheRbtz
+2
Перечитайте «Disclaimer» и второй абзац «Варианты решения проблемы»
SaveTheRbtz
+1
Проблему одновременного перестроения кеша описывают «маленькие красные горбики», которые после применения патча исчезли.
SaveTheRbtz
0
Мы админы/программисты, а не НОКи. Специка нашей работы не подразумевает знания всего этого.
SaveTheRbtz
0
Слишком много всего нужно учитывать: Broadcast штормы, ARP спуфинг, STP root hijack, VLAN hopping. Это только то что с ходу вспомнилось, на практике я думаю на практике там много больше всего(соответственно ACL'и на свитчах будут гигантские). Так что лучше перестраховаться и давать клиентам L3.
SaveTheRbtz
0
Основной смысл multicast адреса на L2 в том, что даже умные свитчи понимающие IGMP/MLD не будут заглядывать в L3 заголовок для определения типа пакета — оно не нужно ибо всё отражено в MAC-адресе(хоть и не без false-positives). Да и в FDB, насколько я понимаю, хранятся не IP'шники, а MAC'и.
Так же заметьте, что multicast трафик не будет нагружать CPU железки которая его не должна принимать. Сравните вывод tcpdump и tcpdump -p.
SaveTheRbtz
0
Есть 2 вопроса:
1) Почему STP BPDU «который явно должен рассылаться броадкастом и всем» шлётся не на FF:FF:FF:FF:FF:FF?
2) Зачем конечному хосту не совместимому со стандартом 802.1D получать BPDU?
SaveTheRbtz
0
На этом месте спотыкались люди даже, разбирающиеся в сетях.
Приведу тут ссылку на самый достоверный источник(с) Multicast address