Навеяно постом уважаемого 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 является фреймворком для построения таких систем. Примеров кода в статье нет, статья больше вводная, хоть и содержит в себе достаточно практической информации.

Вступление

Продолжу цикл статей на тему «Apache 2.x под наблюдением. Мониторинг загрузки системы веб-сервером». Опять же под рассмотрением остается известный ранее[2] модуль Apache — mod_performance. На время написания этой статьи на сайте модуля[1] была выложена для доступа новая версия модуля — 0.2. Дальнейшее повествование в статье будет по принципу «Вопрос-Ответ».

Apache 2 под наблюдением

Вступление

Уже написано немало постов на просторах интернета, о мониторинге веб-сервера Apache. При вводе такой фразы, как «мониторинг нагрузки apache» в строке поиска Google, результаты поиска указывают на полезнейший модуль mod_status. А также о еще большей полезности этого модуля в сочетании с perl-расширениями. А если еще и немного пропатчить эти perl-расширения — то вообще супер система получается. Но настроив такую систему — системный администратор на этом, как правило, не останавливается, ему уже необходимо история нагрузки по серверу в целом, потом по каждому хосту, а далее и с точностью до скрипта. И чтоб потом сравнить можно было, а как раньше было, а как теперь нагрузка распределяется.
И вот здесь на помощь может прийти модуль для веб-сервера Apache — mod_performance.

Год назад, как участник академ. программы IBM, я прослушал курс IBM AIX 6 Jumpstart for UNIX Professionals в московском офисе IBM. Инструктор осветил большинство тем, чтобы опытный администратор Linux или UNIX сел за AIX и стал работать, а также рассказал основные положения линейки серверов IBM Power Systems. Как оказалось, это довольно интересные системы Enterprise уровня, которые предоставляют цельные бизнес системы, включающие в себя встроенные средства виртуализации, мониторинга, диагностики и т.д., которые поддерживаются и со стороны операционной системы.
Я не претендую на исчерпывающее описание архитектуры, статья — скорее экскурс в технологию, для общего развития.

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

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

Если в двух словах — мой сервер взломали. Злоумышленник получил пароль к FTP-серверу и в течении почти 10-ти часов скачивал все, до чего дотянулись ручонки. То, как, собственно, был взломан сервер — отдельная история. Вкратце — хакер отправил фальшивый саппорт-тикет моему хостеру с просьбой помочь создать FTP-юзера. И хостер, в общем-то, повелся. Мало того, что создал юзера, да еще и дал ему админские права… Переписку хакера с хостером (мне удалось завладеть копией) я — если хабровчане захотят — выложу обязательно, это отдельная веселуха. А пока просто перечислю шаги, которые я предпринял, чтобы защитить свой сервер и ликвидировать последствия:

2147483647 (2³¹-1), число Мерсенна — максимально возможное значение для 32-битного целого числа со знаком, то есть самое большое целое число, которое можно записать в 32 бита.

Какое отношение это имеет к телефонным номерам? Как ни странно, самое прямое. Оказывается, немалое число американских программистов в целях оптимизации разрабатывают системы, где телефонные номера на сервере хранятся в виде 32-битных целых чисел. Таким образом, максимально возможный телефонный номер в США равняется (214) 748-3647, где 214 — это код Далласа. При внесении в базу данных большего числа, сохраняется максимально возможный номер 2147483647.

Скотт Гатри анонсировал у себя в блоге выпуск финальной версии Web Farm Framework Version 2.

Web Farm Framework – это дополнение к серверу IIS7, которое предназначено для быстрого создания веб-ферм, наполнения контентом, масштабирования, использования балансировщиков нагрузки и централизованного управления множеством серверов одновременно.

Во второй версии инструмента, согласно записи блога, добавлены следующие возможности:

• инструмент Workflow Builder для определения и планирования задач, которые должны быть выполнены на всех серверах;
• поддержка Windows Credential Store позволит сохранить полномочия администратора используемые для инспекции серверов в безопасном хранилище Windows Credential Store;
• поддержка сторонних балансировщиков нагрузки через расширения Web Farm Framework позволит интегрировать Web Farm Framework с аппаратными балансироващиками вместо использования модуля IIS Application Request Routing;
• улучшена поддержка операций с MSDeploy;
• улучшена поддержка задачи синхронизации большого количества файлов.

Дополнительную информацию по Web Farm Framework можно получить по следующим ссылкам:

• запись блога Скотта Гатри с описанием возможностей Introducing the Microsoft Web Farm Framework;
• замечания к выпуску Download the Web Farm Framework V2 Release;
• документация по Web Farm Framework 2.0;
• форум посвященный Web Farm Framework.

Загрузить финальную версию Web Farm Framework 2 можно по следующим прямым ссылкам: для x86 и для x64. Либо можно воспользоваться установкой через Web Platform Installer.