Доброго времени суток дорогой %username%!
Хотелось бы поздравить с праздником всех админов и в честь этого накатило на меня написать пост. По роду своей деятельности (*nix админ), ко мне обращаются знакомые с различными просьбами о помощи по серверам. Обычно просьбы в духе — у нас стал тормозить сайт, или что-то у нас повисло и т.п. Очень часто, проблемы возникают из-за действий программистов, которые не всегда понимают что делают, либо не понимают последствий того, что они делают. Посмотрев на это все, я решил поделиться с вами некоторыми случаями и наставлениями.
Изначально, думал назвать пост «прекратите админить» и собрать в нем типичные ошибки программистов админов, однако мысль пошла немного иначе, поэтому заголовок получился такой. Заранее хочу извиниться за сумбурность поста, просто накатило что-то написать и как мысль пошла, так и написал.
Случай 1.
— “Антон, у нас стал тормозить сайт. Посмотри?”
Формулировка достаточно стандартная, поэтому для получения какого-либо понимания о происходящем лезу по ssh на сервер.
Заглядывая в top, вижу php процесс, съедающий кучу ресурсов. Что же это? Никакого криминала лишь — remove_old_thumbs.php. Как можно догадаться, он удаляет старые миниатюры изображений. И все бы ничего, но делает это он очень активно.
iotop рассказывает о том, что скрипт очень активно мучает жесткий диск. Оно и понятно, шерстить по папкам и удалять тысячи файлов дело ресурсоемкое, особенно на виртуалках. Решение?
ionice -c3 php remove_old_thumbs.php
Так-как процедура удаления старых миниатюр не критичная, и не требует высокого приоритета, можно ее запустить с низким I/O приоритетом. Запускаем — процесс пошел более тихо, сайт перестал тормозить, миниатюрки потихоньку удаляются — все счастливы.
Случай 2.
— “Антон, мы тут миниатюры начали делать, но что-то все тормозит”
Чтож, посмотрим. Вот те на. Ссылки на миниатюры выглядят таким образом. thumb.php?image=images/12311.jpg. Чтож, тут приходится поковыряться в коде.
— Картинки для миниатюр лежат в одной папке, а их под миллион. Незачем насиловать fs.
— Скрипт не сохраняет сгенерированные миниатюры. На каждое обращение он генерирует новую миниатюру — не комильфо господа!
— Генерация миниатюр для всех картинок займет продолжительное время.
Разбираем случай. Для начала, хорошо бы разложить все картинки по папкам. Предложено раскладывать по дате, дату брать из публикации. С этим особых проблем нет, все прозрачно и понятно. И получилось у нас как-то так: images/2013/08/12311.jpg.
Чтобы убить последние 2 пункта, было предложено сделать адреса миниатюр такими thumbs/2013/08/12311.jpg, а в nginx настроить правило, проверяющее наличие файла по указанному url и в случае отсутствия перенаправлять запрос на thump.php. В свою очередь thumb.php генерирует миниатюру, показывает ее клиенту и складывает на диск по нужному адресу. Таким образом мы разгрузили cpu и fs, а сайт залетал.
Случай 3.
— “Антон, у нас стал тормозить сайт. Посмотри?”
В процессах висит 10 процессов remove_old_thumbs.php. Ребят, ну давайте в скриптах, запущенных про крону, делать проверку на запущенность? Хотябы создавая lock-файл в /tmp, а при завершении скрипта с помощью register_shutdown_function вызывать функцию, удаляющую этот файл. Быстро и просто.
Случай 4.
Сильно подробно я не буду на этом останавливаться, тема хоть и очень актуальна, но каждый случай строго индивидуален. На память я пример не воспроизведу, но если коротко то:
«SELECT * FROM posts» — мы вытянули всю базу постов, со всеми описаниями и почим мусором и активно работаем с этим массивом данных, хотя из всего массива нужен лишь id и poster_url.
«SELECT description FROM posts WHERE post_time > '2013-01-01' AND post_moderated = '1' ORDER BY name DESC» — Представьте этот запрос с кучей join'ов и весьма массивным. И почему он вдруг тормозит? А все потому что нет индекса по полю name, а про EXPLAIN новые программисты не слыхали.
Чтож. Приведенные случаи тянут на ошибки программистов. В чем же можно упрекнуть админов?
Для начала вот этим:
ssh://root:om7ooS3righoob4Xe7ri@hostname
В 90% случаев, удаленный доступ к серверам осуществляется от пользователя root и практически сразу, эти сервера начинают брутфорсить. Это не есть правильно.
Что можно сделать? Для начала создать пользователя, под которым потом заходить по ssh. А затем, запретить авторизацию от рута (PermitRootLogin yes) в sshd_config. Чтобы получить права рута под юзером, можно набрать “su -” или настроить sudo. Не сложно же?
Что можно сделать еще? Можно запретить доступ к ssh с неизвестных IP и не обязательно писать пачку правил для iptables, достаточно подправить пару файлов.
hosts.deny
sshd: all
hosts.allow
sshd: 123.231.132.213
И все! Мы запретили ходить на сервер по ssh всем, кроме 123.231.132.213.
Ок, что еще?
[root@localhost ~]# ps auwx | grep php
root 795 0.0 0.5 321152 9948? Ss июл22 0:10 php-fpm: master process (/etc/php-fpm.conf)
root 884 0.0 0.3 321696 6724? S июл22 0:00 php-fpm: pool www
root 885 0.0 0.3 321696 6644? S июл22 0:00 php-fpm: pool www
root 886 0.0 0.3 321696 6720? S июл22 0:00 php-fpm: pool www
root 887 0.0 0.3 321728 6720? S июл22 0:00 php-fpm: pool www
root 888 0.0 0.3 321728 6728? S июл22 0:00 php-fpm: pool www
Зачем php скриптам выполняться от рута? Зачем?! Все равно что оставлять ключи от машины, в самой машине. Решение в каждом случае будет разное, в данном случае в конфиге php-fpm.conf юезер меняется на нужного.
Те, кто не стал запускать скрипты от рута, грешит другим — chmod 777. Не буду расписывать последствия и способы лечения, скажу лишь одно. Выставляйте права на файлы обдумав свои действия. И никогда не выставляйте их подобным образом
“chmod 777 -R. “. Волею судьбы, вы можете поломать ОС, запустив команду не в той папке.
Множество админов грешат тем, что компилят софт и ставят его в систему. Не возьмусь сказать, что это огромное зло, но все же это зло. Знакомо ./configure && make && make install? Ребят, не поленитесь найти пакет. Если нет пакета, попробуйте воспользоваться тем же checkinstall.
На самом деле, различных случаев очень много. Разбирать их можно долго и упорно, однако я бы хотел обратиться к программистам. Ребят, если вы поддерживаете сайт с серьезной посещаемостью, занимаетесь оптимизациями и создаете какой-либо суровый функционал, обратитесь за советом к опытным коллегам (особенно админам). Они вам помогут советом и спасут от страшных и не очень ошибок.
Автор: Wendor
