Хочу рассказать историю жизни сервера в кампусной сети Новосибирского университета, которая началась в далеком 2004 году, а так же этапы его оптимизации и даунгрейдинга.
Многие вещи в статье покажутся общеизвестными хотя бы по той причине, что речь пойдет о событиях почти десятилетней давности, хотя на тот момент это были передовые технологии. По той же причине кое что вообще потеряло актуальность, но далеко не все, так как сервер до сих пор живет и обслуживает сетку из 1000 машин.

Добрый час, Хабровчане!

Хочу поделиться своим опытом автоматизации процесса установки и настройки FreeBSD с помощью sh (bash). Дело было так:
Однажды в компании возникла необходимость поднять несколько серверов на FreeBSD. Поставив одну, следом за ней вторую и третью ось, мы с коллегой (в штате всего два айтишника) задумались в сторону автоматизации этого процесса путем написания скрипта, выполняющего настройку свежеустановленной ОС. Задача написания легла на мои плечи. Коллега занялся решением вопроса автоматической установки, о чем я расскажу в другом посте. Итак, приступим!

Всех приветствую!
В данном топике я расскажу о нашем реальном процессе перехода с системы HP EVA P6300 на новую СХД, опишу наши ожидания и что из них было получено, а что — нет. В тексте процесс выбора систем будет очень кратким, хотя процесс выбора занял ОЧЕНЬ много времени. Не привожу никаких данных IOPS дабы не начинать cockfighting полемику. Не в этом цель статьи. Я просто описываю свой реальный опыт.

Zipkin — это система распределенной трассировки, которая помогает нам собирать данные о времени выполнения всех разрозненных служб на Twitter. Он управляет сбором и поиском данных через сервисы Collector и Query. Мы проектировали Zipkin по образцу Google Dapper. Подпишитесь на @ZipkinProject и следите за развитием событий.

И зачем эта распределенная трассировка?

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

Доброе время суток, хаброжители!

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

Итак, о задаче: есть два канала интернет, шлюз на FreeBSD

gate# uname -a
FreeBSD gate 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Thu Nov  1 06:48:52 OMST 2012     root@gate:/usr/obj/usr/src/sys/GATE  amd64

Не то, чтобы необходимость, но желание создать гибкую систему с балансировкой трафика по каналам и желание получить премию от руководства.
Канал №1: безлимитка, скорость 7 Мб, реальный ip-адрес
Канал №2: безлимитка, скорость до 60Мб, реальный ip-адрес.
Со стороны провайдера были установлены шлюзы, через которые реализую DMZ на «ловушки» для хакеров, поэтому настройки PF и SQUID минимальны

VMware vSphere VAAI — кто он такой?

Немного теории про VAAI:

Это комплекс технологий компании VMware, разработанный в сотрудничестве с различными производителями СХД, предназначенный для передачи некоторых операций виртуальных машин по работе с дисками на сторону массива. В этом случае хост-сервер виртуализации при выполнении стандартных процедур в среде виртуализации при работе ВМ с дисковой подсистемой просто дает команду массиву сделать определенные действия, при этом сам хост не гонит через себя все те данные и команды, которые он раньше был вынужден прогонять. То есть, это — Hardware Offloading операций с СХД.
На этом с теорией заканчиваем.

Практика

Недавно в моем парке появился новый дисковый зверек HP P2000 G3 MSA DC.
Система виртуализации построена на решении от VMware. А как многим известно, а начиная с версии 4.1 платформа виртуализации стала поддерживать технологию VMware vSphere VAAI, или другими словами vStorage API for Array Integration.

Наверное, некоторые из вас слышали о халяве под названием x32 ABI.

Вкратце о x32 ABI

Если вкратце, то это возможность использовать все преимущества 64-битной архитектуры, но при этом сохраняя 32-битные указатели. Потенциально при этом приложение будет расходовать меньше памяти, хоть и не сможет адресовать более 4 ГиБ памяти.

Пример. В своём коде вы определяете массив целых чисел и заполняете его значениями. Сколько при этом вы расходуете памяти? Если очень грубо изобразить, то получится примерно так:
32 бита: Указатель + Счётчик числа элементов + N целых чисел = N+2 32-битных числа
64 бита: Указатель + Счётчик числа элементов + N целых чисел = N+2 64-битных числа = 2N+4 32-битных числа
Вот инженеры и задумались: а что если попробовать использовать 32-битные указатели на 64-битной архитектуре? Архитектура X86-64 имеет систему команд CISC и позволяет это сделать. В этом случае наш массив выше будет расходовать памяти 2N+3 вместо 2N+4. Экономия конечно же незначительная, но дело в том, что в современном коде количество разного рода указателей в структурах нередко доходит до десятка, и использование коротких указателей потенциально позволит экономить до 50% памяти (в идеальном случае).

Для тех кому надо расчёты точнее:
* Насколько большие массивы (и значения) в PHP? (Подсказка: ОЧЕНЬ БОЛЬШИЕ)
* Сколько памяти потребляют объекты в PHP и стоит ли использовать 64-битную версию?

Но как оказалось халявы не будет.

Навеяно постом уважаемого amarao о том, как надо измерять производительность дисков.

Цель:

Протестировать производительность имеющихся в наличии средств хранения информации и убедиться в верности выбранной методики, а также понять разницу в производительности между разными видами накопителей, а также enterprise-level и consumer-level жёсткими дисками.

Оборудование:

1. SD-карта Sandisk Class 10 UHS 1 Extreme Pro 8 GB (до 95 Мбайт/с чтение, до 90 Мбайт/с запись)
2. SD-карта Team Class 10 32 GB (до 20 Мбайт/с)
3. SD-карта Transcend 2GB без класса скорости
4. SSD-диск OCZ-AGILITY3 60 GB
5. SATA-диск consumer-level Hitachi Deskstar HDS723020BLA642 2 ТБ 7200 об/мин, 64 Мбайт
6. SATA-диск enterprise-level Western Digital RE3 WD2502ABYS-23B7A0 250 GB 7200 об/мин 16 Мбайт
7. SATA-диск consumer-level Seagate Barracuda 7200.11 ST3320613AS 320 GB 7200 об/мин 16 Mбайт
8. CD-ROM
9. RAM-диск /dev/ram в Linux

Методика тестирования:

Методика полностью описана в посте. Есть правда несколько не совсем понятных моментов:

Мы подбираем такую глубину параллельности операций, чтобы latency оставалось в разумных пределах.

Задача подобрать такой iodepth, чтобы avg.latency была меньше 10мс.

Так как в тестировании используется не СХД и не диски SAS, а различные накопители SATA, то параллельность нам измерять нету смысла.
Очищать диск перед каждым тестированием (dd if=/dev/zero of=/dev/sdz bs=2M oflag=direct) очень времязатратно, поэтому будем это делать перед тестированием один раз на каждый накопитель.
Тестировать весь диск полностью очень времязатратно, поэтому будем использовать тестирование в течении 30 секунд.
Итак, сформулируем методику тестирования для нашего случая:
Получить значение IOPS, выдаваемое накопителем при произвольном чтении и записи блоками по 4 Кбайт и задержке avg.latency не более 10 мс за время теста в 30 секунд. Также для полноты картины измерим скорость линейной записи.

Параметр thread_cache_size играет немаловажную роль в производительности нагруженного MySQL-сервера. В некоторых случаях можно увеличить производительность на 30-50%.

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

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

Предупреждение: много букв, долго читать.

Лирика

Очень частой проблемой, является попытка понять «насколько быстрый сервер?» Среди всех тестов наиболее жалко выглядят попытки оценить производительность дисковой подсистемы. Вот ужасы, которые я видел в своей жизни:

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

Это всё совершенно ошибочные методы. Дальше я разберу более тонкие ошибки измерения, но в отношении этих тестов могу сказать только одно — выкиньте и не используйте.

Подробные инструкции, которые даются на code.google позволят вам:

• Сжать все многочисленные скрипты JS и стили CSS
• Соединить все полученные файлы в один JS и в один CSS
• Сжать полученные два файла в формат GZIP, который понимают почти все браузеры и умеют распаковывать на лету
• Прописать такой .htaccess, который заставляет браузеры кэшировать данные два файла

Всё это будет происходить при запуске единственного скрипта compress.php

Для примера, результат сжатия скриптов моего сайта:

• JS: сжато в gzip 26 698 B, сжато без gzip 95 796 B, было 120 147 B
• CSS: сжато в gzip 46 049 B, сжато без gzip 160 001 B, было 281 870 B

Получается, что экономия трафика составляет 329 270 B. Но основной выигрыш для скорости загрузки в том, что теперь загружается не 14 файлов, а всего 2 (а это намного быстрее, так как браузер не тратит время на запросы). Причём делается это один раз, а не динамически силами самого сервера (тем более, что не все сервера поддерживают подобное конфигурирование сжатия для экономии ресурсов процессора).

В итоге, получится:

<link rel="stylesheet" type="text/css" href="min/styles_1349888114.cssgz" />
<script src="min/all_1349888114.jsgz" /></script>

Оригинальный текст — что-то вроде сборника ссылок с минимальным комментарием и картинкой. Я постарался немного дополнить статью, поэтому это теперь не совсем перевод, а скорее «расширение» оригинала. P. S. Да простят меня уважаемые читатели за немного издевательские хабы.

Такое чувство, что люди уже запустили веб-сервер на основе всего, до чего только добрались их руки. Ниже список нескольких очень нестандартных подходов к выбору железа для сервера.

Spud: Веб-сервер, работающий на электричестве из картофеля

Нужны какие-нибудь комментарии? По-видимому они столкнулись с проблемой гниения картофеля.

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

На одном из проектов часто разворачивались/удалялись новые ноды в облаке, соответственно, появилась задача добавления/удаления новых хостов в Zabbix для мониторинга доступности и снятия статистики. Для саморазвития было решено использовать библиотеку zabbix API на питоне. Это был первый опыт написания скриптов, поэтому буду благодарен за отзывы и замечания по коду.

Как вы уже могли узнать, Instagram продается Facebook за $1 млрд. У многих возник вопрос: За что такие деньги? Кто-то на хабре сравнил это с бумом доткомов. Да только весь этот бум на одном Facebook и держится.

В течении двух лет CEO Instagram Kevin Systrom думал, как же монетизировать свое быстрорастущее детище, но так и не придумал. При том много раз просказльзывали слухи о его отказе в сделке с Facebook. Автоподсказчик Google уже давно выдавал первым вариантом к запросу «kevin systrom» фразу «Kevin Systrom net worth». Дела шли в гору и без Facebook.

Неделю назад они выпустили приложение на Android и продались Facebook за сумму с 9 нулями в долларах. Владельцы андроидов были рады:

Разработчики же, не очень: «Куда так топят? За что им платят? Я тоже так могу, там же ничего сложного и инновационного!» кричал каждый второй разработчик на Android / iOS.

Лично я ждал падения сервиса в день релиза приложения в магазине Google Play. Но этого не случилось. Количество зарегистрированных пользователей в первые 24 часа составило около миллиона человек. Немалая цифра, я вам скажу.

И как же команде из 9 человек удалось вытерпеть такой наплыв и не сломаться?

Добрый день, уважаемые хабрапользователи, несмотря на тенденцию падения Oracle в глазах системных инженеров и компаний заказчиков. Операционная система, теперь уже Oracle Solaris продолжает жить и радовать наш глаз.
Недавно столкнулся с вопросом оптимизации некоторых параметров TCP/IP стека. Данная тема показалась мне интересна, многим она может показаться уже избитый, а кого то познакомит с новыми интересными моментами настройки. Итак начнем…

Есть у меня серверок (да, да, именно серверок, сервером его назвать сложно). Железо старенькое (2 гига оперативы, AMD Athlon(tm) 64 Processor 3500+, програмный RAID). Админю я его сам, без особых навыков и познаний. Когда-то давным давно (больше года назад) поставил на него Debian 5.0 Lenny (это была вторая в жизни установка linux-системы, до этого ставил только Ubuntu на рабочий ноутбук) и панель управления ISPConfig3 по мануалу. Держу на нем несколько (штук 40) сайтов друзей и клиентов, Redmine, SVN и еще немного по мелочам.
Периодически все это безобразие падает (load average > 20), и приходится на сервере раз в пару часов перегружать apache или высасывать из пальца очередную попытку оптимизации. В общем полный раздрай и разруха. И вот в одну прекрасную субботу я подумал — а почему бы не решить вопрос раз и… И вот в общем.
Под катом — история убитых выходных + предыстория. Интересна в первую очередь мне, чтобы потом легко вспомнить что именно и зачем я ставил. Может быть интересна новичкам в интересном и нелегком (ох, ...) деле серверной оптимизации постепенным(!) переводом сайтов из-под Apache c его ModRewrite под Nginx (кстати, правильно это слово читается «энжинкс»меня поправили, Сысоев на конференциях не раз говорил, что название сервера стоит читать, как «энжин-икс», спасибо bayandin и DorBer ). Возможно, будет интересна более-менее опытным товарищам, оказавшимся в тех же условиях (Debian Lenny, ISPConfig3, слабое железо, несколько хороших, не сильно хороших и разных сайтов). И более опытным может быть интересно зайти, оставить пару комментариев.

Уважаемые жители Хабра!

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

Всё. На этом можно было бы статью закончить, так как эта аксиома повторяется из года в год на форумах и конференциях и кочует из текста в текст на всех технических ресурсах. Однако это ёмкое «Всё» не поясняет деталей. Ведь существует достаточно широкая прослойка программистов, движки и проекты которых справляются с задачей без мемкеша и шардинга. Но момент нагрузки приходит, и приходится разбираться.
Для таких людей я и разобрал на запчасти это универсальный ответ высоконагруженных проектов.
Ограничимся изучением системы для веба. Попросту говоря, на привычном обычном сайте. Используете ли вы готовую CMS, или уже выросли до каркаса, или написали «с нуля» код для нестандартного проекта – основными элементами процесса приёма-отдачи данных всегда будут одни и те же узлы. Я их рассмотрю с точки зрения «Где что можно закешировать».

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

    В этой статье, мне бы хотелось рассмотреть один из необычных способов оптимизации приложения, а именно использование проекта Gearman для распределения задач. Gearman является фреймворком для построения таких систем. Примеров кода в статье нет, статья больше вводная, хоть и содержит в себе достаточно практической информации.