Рубрики
Наследие

Хайлоад: Типичные ошибки клиентов

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

Мода важнее здравого смысла

Процитирую диалог с одним из клиентов:

— Сколько стоит поставить nginx?
— Зависит от задачи, а в чем она состоит?
— У меня сайт медленно работает, и я слышал, что nginx позволяет его ускорить!
— Я вижу по анализатору, что на сайте более 200 изображений, а нагрузка на сервер при этом 2-3%. Проблема не в сервере, а в том, что слишком много изображений, на погрузку которых браузер тратит свои ресурсы.
— А разве nginx не ускорит их отдачу?
— Ускорит, но проблема не в скорости их загрузки, а в большом числе.
— Что же делать?
— Переписать дизайн, и вынести картинки подгрузкой в css.
— Это слишком долго, я хочу nginx и готов заплатить.
— Хорошо, но предупреждаю — это не сильно повлияет на скорость загрузки сайта.

В результате, после установки nginx, клиент был вынужден обратиться к услугам профессионального верстальщика, который сократил его 200+ изображений до 83-х, вынеся все повторяющиеся элементы в css.
Его проблема была не в том, что он не понимал как пагубно влияет такое число изображений на скорость открытия страницы, а безумное следование моды: медленно работает — ставь nginx!

Гадание вместо статистики

Процитирую диалог с одним из клиентов:

— Мне надо настроить MySQL!
— А что с ним такое?
— У меня клиенты на хостинге жалуются, что их сайты тормозят!
— Но я вижу, что mysql потребляет 2-5% RAM и 15-20% CPU. И нагрузки никакой нет, все запросы успешно попадают в кеш.
— Тогда надо поставить xcache для php, выдав ему больше памяти, потому что скорость открытия сайтов ну очень низкая!
— Я могу поставить, только не гарантирую, что это поможет.
— А что же делать?
— Заказать у меня аудит сервера, по результатам которого работать над найденными проблемами.
— Хорошо, заказываю.

По результатам анализа, проблема оказалась в медленном выполнении кода SAPE, причиной которого стала медленная работа DNS ресловеров, предоставленных Дата-Центром: из 3-х работал только один, да и то с большими задержками.
Проблема решилась прописыванием DNS ресловера Goole 8.8.8.8 и 8.8.4.4

Наличие практического опыта без фундаментальных знаний

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

— Мне нужен аудит двух серверов, почему на одном сервере InnoDB работает правильно, а на другом — нет.
— А что значит правильно? Задачи у серверов одинаковые?
— На одном сервере после переноса базы в InnoDB, сайт стал открываться быстрее. А на другом сервере — нет.
— Хорошо, разберусь.

На одном сервере сайт был на CMS Drupal, который умеет использовать InnoDB и имеет собственные схемы кеширования. Проблем никаких не возникало.
На другом сервере сайт был на CMS DLE, в запросах постоянно был select count с последующими множеством update. Так как CMS была лицензионная, примеры таких запросов были отправлены разработчику, который рекомендовал отключить счетчики страниц. После чего проблема пропала.
Провести сравнение запросов на серверах клиенту и в голову не приходило, он занимался тем, что постоянно менял параметры в конфиге mysql, в надежде, что станет быстрее работать.

Неумение разделять задачи

Один очень крупный заказчик, занимающийся стримингом и имеющий сайт, входящий в top-3 одной из узких ниш, пожаловался, что возникла проблема с конвертацией видео.
Сервер, который занимался конвертацией был очень мощный, но уже не смог обрабатывать все поступающие видео от пользователей с должной скоростью.
Мне нужно было произвести анализ, какой сервер лучше выбрать из ряда предложений дата-центра.
Как оказалось, конветрация более всего использовала ресурсы процессора и диска, в меньшей степени — оперативной памяти, которая пустовала на 90%.
Я предложил ему вместо перехода на новый сервер, взять 4-е более слабые модели, которые по цене выходили дешевле.

— Нет, мне это не подойдет. Я буду конвертировать 4-е разных файла от пользователей, но конвертация все равно будет медленной, я уже это пробовал! Мне нужно один, но быстро!
— Так я для этого и советую взять 4-е сервера. Разделить видео на 4-е части, затем каждую часть сконвертировать на своем сервере. После чего склеить.
— А разве так можно?!
— Нужно.

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

Отсутствие кеширования


— У меня большая нагрузка на MySQL. Посоветовали memcache! Я поставил — не помогло!
— В смысле — поставил?
— Ну сделал apt-get install memcached php5-memcache и рестартовал апач.
— И все?
— Да! А разве еще что-то надо?

Множество людей тратит невероятно большие деньги на покупку мощных серверов. И все это из-за недостаточности понимания того, что же такое на самом деле является кеширование.
В качестве примера, я приведу решение проблемы на биржевой системе.
Сервера постоянно получают информацию по стоимости акций, клиенты просматривают графики, покупают-продают, вобщем как обычно.
При этом используется черезвычайно мощный сервер и программисты уверяют, что действительно оптимизировали все что могли, и проблема в недостатке железа. Но владелец проекта приводит другую статистику — с ростом каждой тысячи активных пользователей приходится брать вдвое мощный сервер. Сейчас их 4000 и если рост будет идти также быстро как и сейчас, то в скором времени придется переезжать на суперкомпьютер.
Аудит шел достаточно долго — на первый взгляд действительно, все было кешировано:

  • повторяющиеся запросы складывались в memcache
  • был установлен и настроен xcache, который хранил все php скрипты в оперативной памяти
  • все статичные файлы выдавались с правильным заголовком expired

А затем я нашел директорию, в которой были сотни тысяч файлов. На ее открытие уходило несколько секунд.
Дословно процитирую диалог:
— Это графики пользователей, которые они хотят получать. Там можно накладывать несколько графиков в один. У каждого пользователя — свои графики.
— А сколько всего акций и сколько всего пользователей?
— Примерно 400 акций и около 60000 пользователей.
— А если выдавать графики для каждой акции, а потом просто склеивать картинки в одну общую?
— Уже так думали делать, но будет большая нагрузка на диск — их все равно придется записывать перед отдачей.
— А зачем? Пусть они собираются на стороне клиента.
— Но как???
— При помощи javascript.
— Склеивать картинки через javascript на стороне клиента?
— Нет. Выдавать цифры, с помощью которых ajax будет рисовать графики, а цифры отдавать через push с помощью…
— Спасибо, уже не надо продолжать, поняли свою ошибку.
Кеширование — это не просто сохранение картинок на диске, это немного нечто большее…

Попытка масштабировать без понимания сути проблемы


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

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

Наличие единой точки отказа

Компания, поставлявшая услуги хостинга картинок, решила подумать о защите от DDOS атак. Не смотря на многочисленные доводы о том, что лучшая защита от DDOS — это кластер грамотно настроенных серверов с фильтрацией, технический директор компании решил использовать Cisco RiverGuard для защиты.
Шло время, одного сервера стало недостаточно, и незаметно их число возросло до шестидесяти. Сервера закупались, ставились в стойки, но весь трафик продолжал идти через циску.
А потом наступила проблема — трафик перестал расти. Раньше, с ростом числа серверов трафик рос пропорционально, но сейчас перестал.
Я снял статистику с циски по snmp и убедился, что эта железка испытывает явные проблемы с перегрузками. Техдиректор сразу решил, что началась DDOS атака.
Однако по анализу логов все было чисто. Проблема была явно в перегрузке точки, через которую шел трафик.
Тем не менее, владельца бизнеса это не убедило, так как технический директор мотивировал тем, что «Cisco — это сила, а частный консультант — это обычный человек».
Проблема продолжалась в течении года, пока наконец под моими многочисленными уговорами, технический директор не отправил кейс с графиками загрузки.
Ответ пришел достаточно быстро, в котором однозначно указывалось, что этот девайс перестанет нормально работать, если число одновременных запросов будет выше 70k.
После этого владелец наконец рискнул убрать Guard с канала, напрямую дав его на все стойки. Разумеется, трафик начал расти.
Однако тот, кто прочитав, подумает, что единая точка отказа это Cisco RiverGuard, тот ошибется. Разумеется, единой точной отказа был технический директор.

Белогривые лошадки

У нас есть игра для социальной сети Вконтакте. Мы хотим сделать версию для Facebook, но боимся, что сервер не выдержит. По этому мы перешли на облако, а кластер для нас это слишком дорого для начала. Но потом, когда мы заработаем, то обязательно перейдем на кластер.
Когда у вас появляется кластер, то вы все равно будете иметь некий лимит ресурсов, определяемый числом серверов в кластере.
Облако напротив — дает мифическую свободу ресурсов, позволяя на какой-то момент не задумываться, а просто оплачивать перерасход ресурсов, в надежде, что прибыль окупит затраты.
Коварство заключается в том, что рост нагрузки не связан линейно с ростом посещаемости и целиком зависит от радиуса кривизны приложения. Наверное каждый слышал притчу о награде изобретателя шахмат?
На первую клетку шахматной доски — одно зернышко, на второе — два, и так далее.
Так и с облаками. На первую тысячу посетителей — один слот, на вторую — два, на третью — четыре. А вот когда их становится пять, то внезапно(!) приходит озарение, что следующую тысячу «мы не потянем», полученных денег едва хватает чтоб оплатить за облако, а на оптимизацию кривого движка игры уже совсем ничего не осталось.

Заключение

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

Рубрики
Наследие

Расширяем лог почтового сервера

Вам хотелось бы знать, с какого сайта и каким скриптом было отправлено то или иное письмо? Думаю, что да.
Однако стандартный почтовый сервер такой информации не ведет.

Так исправим этот недостаток!

cd /usr/sbin
mv sendmail sendmail.org
vi sendmail

И напишем небольшой скрипт:

#!/bin/sh
logger -p mail.info sendmail-ext-log: site=${HTTP_HOST}, client=${REMOTE_ADDR}, script=${SCRIPT_NAME}, pwd=${PWD}, uid=${UID}, user=$(whoami)
/usr/sbin/sendmail.org -t -i $*

После чего сделаем файл исполняемым:

chmod +x sendmail

Все. Теперь лог будет иметь всю необходимую информацию.

Рубрики
Наследие

Быстрое восстановление аккаунтво cpanel

Предположим, что в /home находится множество резеврных копий акканутов в формате cpanel и их необходимо максимально бытро восстановить

Для этого используем следующий скрипт:
for i in `ls cpmove-*.tar.gz`; do a=`basename $i .tar.gz`; /scripts/restorepkg `echo $a | cut -d — -f2`; done

Рубрики
Наследие

Смена кодировки у базы и всех ее таблиц из командой строки

Предположим у нас есть база mydb, в неверной кодировке (latin1) по умолчанию. Необходимо выставить ее в utf8. для этого используем скрипт:

echo «ALTER DATABASE mydb DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;» | mysql; for i in `mysqlshow mydb % | grep -v + | cut -d ‘ ‘ -f2;`; do echo «ALTER TABLE mydb.$i DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;» | mysql ; done

В скрипте mydb замените на название своей БД.

Рубрики
Наследие

Оптимизируем VDS под файл-хостинг с использованием nginx

Если использовать VDS в стандартной поставке с веб-сервером apache, то рано или поздно возникнет проблема с недостатком памяти. И это вполне логично:

Каждый из потомков апача отнимает достаточно много памяти

При отдаче медиаконетнта и просто файлов больших размеров
возникают медленные коннекты и число потомков неумолимо растет

Для исправления подобной ситуации можно использовать легкий
вебсервер nginx

В качестве примера возьмем VDS с Fedora Core 2 от keyweb, где традиционно не стоит yum и проведем установку и конфигурацию nginx:


wget http://download.fedora.redhat.com/pub/fedora/linux/core/2/i386/os/Fedora/RPMS/gcc-3.3.3-7.i386.rpm
wget http://download.fedora.redhat.com/pub/fedora/linux/core/2/i386/os/Fedora/RPMS/pcre-devel-4.5-2.i386.rpm
wget http://download.fedora.redhat.com/pub/fedora/linux/core/2/i386/os/Fedora/RPMS/binutils-2.15.90.0.3-5.i386.rpm
wget http://download.fedora.redhat.com/pub/fedora/linux/core/2/i386/os/Fedora/RPMS/cpp-3.3.3-7.i386.rpm
wget http://download.fedora.redhat.com/pub/fedora/linux/core/2/i386/os/Fedora/RPMS/glibc-devel-2.3.3-27.i386.rpm
wget http://download.fedora.redhat.com/pub/fedora/linux/core/2/i386/os/Fedora/RPMS/glibc-headers-2.3.3-27.i386.rpm
wget http://download.fedora.redhat.com/pub/fedora/linux/core/2/i386/os/Fedora/RPMS/glibc-kernheaders-2.4-8.44.i386.rpm
wget http://download.fedora.redhat.com/pub/fedora/linux/core/2/i386/os/Fedora/RPMS/pcre-4.5-2.i386.rpm
rpm -Uvh *.rpm
wget http://sysoev.ru/nginx/nginx-0.4.13.tar.gz
tar xzf 0.4.13.tar.gz
cd nginx-0.4.13
./configure --prefix=/usr/local/nginx --without-http_charset_module --without-http_ssi_module --without-http_userid_module --without-http_access_module --without-http_auth_basic_module --without-http_empty_gif_module --without-http_gzip_module --without-http_rewrite_module --without-pcre
make -s
make install

После чего nginx будет установлен в /usr/local/nginx в минимальной рабочей конфигурации (а значит — максимально быстрый)
Далее следует сконфигурировать его на отдачу файлов по протоколу http. Пример конфигурации nginx.conf:

worker_processes 1;
events {
worker_connections 1024;
}

http {
include conf/mime.types;
default_type application/octet-stream;

log_format main ‘$remote_addr — $remote_user [$time_local] $status ‘
‘»$request» $body_bytes_sent «$http_referer» ‘
‘»$http_user_agent» «$http_x_forwarded_for»‘;

access_log /dev/null;

tcp_nopush on;
keepalive_timeout 15;


server {
listen ваш_ip:80;
root /home/download;
}
}

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

Рубрики
Наследие

Исправляем погрешности в DNS зонах

На одном из серверов под управлением ISP System был обнаружен досадный сбой — панель создала файлы зон, где для субдомена WWW был указан некорректный IP. В результате сайты без www открывались нормально, а с www — нет.
Для исправления этой проблемы было использовано:

[adsense:336×280:1:1]
1. Замена некорректных IP адресов в доменных зонах при помощи perl: perl -pi.bak -e "s/WRONGIP/CORRECTIP/g" /var/named/*.db, где WRONGIP — неправильный IP, а CORRECTIP — соответственно правильный.
2. После исправления всех IP был увеличин serail доменных зон при помощи достаточно известного скрипта zsu.

После проведения этих действий сайты стали откываться корректно. http://forum.searchengines.ru/showthread.php?p=1627459

Рубрики
Наследие

Защищаемся от эксплоита nima salehi

Новая версия эксплоита nima salehi позволяет получить рутовый доступ к серверам под управлением WHM.
Для предотвращения есть минимум три варианта:

1. Самый простой — выполнить команду: touch /tmp/strict.pm ; chmod 000 /tmp/strict.pm; chown root /tmp/strict.pm
2. Более приемлемый — запретить passthru() в php.ini
3. Самый надежный — установить grsecurity ядро с опцией TPE для группы nobody

Рубрики
Наследие

MySQL, кодировки и вопросики вместо русских букв

В предыдущей статье о русификации MySQL было написано как заставить mysql корректно работать с кодировкой utf8.

Но как быть если предположим есть два сервера и на одном из них mysql в utf8 а на другом — в стандартной кодировке?

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

Сначала создадим архив с дампами баз mysql с помощью первого скрипта:

for i in `mysqlshow | grep -v + | grep -v '| Databases |' | cut -d ' ' -f2 | grep -v horde| grep -v mysql | grep -v eximstats`; do mysqldump -f --compatible=mysql40 $i > $i.sql; done; tar czf dump1251.tgz *.sql; rm *.sql

В результате будет создан файл dump1251.tgz — архив со всеми дампами sql в нормальной кодировке. Его необходимо перенести на другой сервер и восстановить с помощью второго скрипта:

for i in `ls *.sql`;do b=`basename $i .sql`;yes | mysqladmin drop $b; mysqladmin create $b; mysql --default-character-set=utf8 $b
После этого вместо вопросительных знаков появятся русские буквы.

Рубрики
Наследие

Технология повышения качества виртуального хостинга

Как можно повысить качество виртуального хостинга при ограниченном бюджете

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

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

Таким образом, аудитория будет находиться в диапазоне, где максимальная месячная цена за хостинг не будет превышать аренду выделенного сервера (X), а месячная сумма потерь за время недоступности сайта (Y) не должна превышать среднеарифметический месячный доход такой компании (Z).

Следовательно, аудитория расположена в диапазоне Z > Y

Рубрики
Наследие

Используем qemu для создания qVDS

Многим хотелось бы иметь на своем сервере возможность для экспериментов без риска или установить другую операционную систему. Конечно, такие технологии существуют уже достаточно давно — VDS, когда на основе одного физического сервера создаются несколько виртуальных.
Однако существует недостаток — необходимо пересобрать ядро с разного рода патчами, что очень рискованно — сервер может не загрузиться с новым ядром.
Для решения этой проблемы мы воспользовались qemu — открытой системой эмуляции как на уровне «железа», так и на UML (только для Linux, естественно).
Однако основным существенным преимуществом на практике является то, установка qemu чрезвычайно проста и не требует пересборки ядра, достаточно распаковать бинарный архив, добавить недостающие библиотеки и qemu готов к работе.

В то же время существуют два серьезных недостатка. Первый — это чрезмерное потребление ресурсов в эмуляции на уровне полной системы, что не позволяет конкурировать на данном уровне с такими технологиями, как OpenVZ, а второй — эмулятор использует GUI, что делает работу с ним чрезвычайно неудобной, особенно, если у Вас к серверу слабый канал.
Но есть возможность избежать этого, запустив qemu в режиме терминала. Мы подготовили два образа: один — мини-образ Linux Debian в состоянии режима basic setup, второй — уже предустановленную FreeBSD с предусмотрительно поднятым ssh-сервером. Пароли также предустановлены — для admin — admin и для root — root. Обязательно смените их сразу после запуска. Скачать архивы с образами и скриптами можно по ftp — ftp://dedic.ru/qemu/, а можно выполнить самостоятельно.

Для дистрибутивов Linux необходимо скачать ISO-образ дистрибутива, и лучше всего, если это будет mini-образ, остальное можно ставить по сети. Затем этот образ монтируем во временную директорию (опция loop) и забираем оттуда само ядро vmlinuz и initrd.img. Запускаем qemu с этим ядром и inird, а в дополнительных опциях передаем вывод на консоль. После запуска qemu мы работаем с виртуальным сервером через консоль. Естественно, что графический инсталлятор лучше не использовать.

В случае же с FreeBSD все еще проще — достаточно включить в конфигурации comconsole и настроить ее, после чего перенаправить ввод-вывод в stdin/stdout.

Для доступа с виртуального сервера в сеть на настоящем сервере необходимо включить форвардинг:
echo 1 > /proc/sys/net/ipv4/ip_forward
и разрещить выход с подсетки 127.20.0.2 (это IP-диапазон виртуальных серверов):
iptables -t nat -A POSTROUTING -s 172.20.0.0/24 -d 0/0 -j MASQUERADE
Для того, чтобы виртуальный сервер был доступен под одним из реальных IP реального сервера, необходим обратный проброс:
iptables -A FORWARD -d 172.20.0.2 -i eth0 -j ACCEPT
iptables -t nat -A PREROUTING -d реальный.ip.тут -p tcp -j DNAT —to-destination 172.20.0.2