Три первых шага к оптимизации LAMP

    Бытует мнение, что связка LAMP (Linux+Apache+Mysql+PHP) не требует особой настройки и работает «из коробки». Это далеко не так. После того, как я долго убеждал товарища установить кеширующий акселератор PHP xcache, я решил провести небольшой эксперимент и попробовать выключить xcache на своём виртуальном сервере, находящемся под небольшой нагрузкой (около хита в секунду). В реальной жизни нагрузка на процессор мала, а вот память загружена сильно, т.к. её немного (256МБайт).

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




    Через полчаса экспериментов система вылезла в жестокий своп и я еле смог вернуть кеширование на место:



    Этот эксперимент, к сожалению, не был чистым, так как я настраивал Apache именно под имеющуюся конфигурацию, и выключение кеша привело к своппингу. Xcache (как и другие PHP-акселераторы) позволяет экономить сразу и процессорное время, и память, и обращения к диску, сохраняя промежуточный код скриптов PHP в оперативной памяти. Несмотря на то, что кеш занимал у меня целых 64МБайт, его отсутствие привело к разрастанию каждого из рабочих процессов настолько, что они вылезли за пределы физической памяти.

    Вынесем три урока оптимизации — по одному на компонент AMP:

    1. Всегда настраивайте Apache так, чтобы выполнение команды ab -n1000 -c100 yoursite/bigscript.php не приводило к свопу. Для этого прочитайте эту статью. «Коробочный» Apache плюс скрипты средней тяжести — верная дорога в пропасть при увеличении нагрузки. Особенно для ограниченных по памяти VDS.
    2. Всегда устанавливайте акселератор PHP. На обычных проектах и CMS (Drupal/Joomla/WP) это принесет ускорение отдачи и снижение нагрузки на процессор в 2-4 раза, а также экономию оперативной памяти. Настраивайте количество кеша, достаточное для хранения активных скриптов (занятость кеша можно мониторить).

    Третий урок — включайте Query Cache в MySQL. Он наглядно иллюстрируется следующим графиком:

    Для более подробных советов по MySQL обратитесь к скрипту tuning-primer.sh, запустив его на живой БД.

    Остальные меры (кроме оптимизации самих приложений) дают эффект послабее, но могут сэкономить ещё много ресурсов. Если интересуетесь — рекомендую прочитать вот эти статьи.
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 84
    • +22
      Не информативно, если честно :) Судя по названию топика ожидал увидеть больше информации :)
      • –2
        А можно услышать более конкретные вопросы? Я готов ответить и уточнить, просто, как мне кажется, для советов 1 и 3 лучше обратиться к указанным мной первоисточникам, а по второму совету уточнять нечего… выбрать из тройки акселераторов лучший сложно, но хорошо работают все три.
        • +1
          Я немного не в тему, но не подскажете толковый мануал по настройке графиков? mrtg или др. :)
          • 0
            Я сам в этом не эксперт, использую munin — и в packageах есть, и работает неплохо, и настройки изначально вообще не требует.
        • 0
          Ну так «Три первых шага». Будем надеяться человек возьмет хороший старт и в процессе напишет что-нибуть мощьное :-) Так как нибуть помощьнее этого: www.opennet.ru/base/sys/mysql_innodb_solaris.txt.html :-)
        • 0
          всегда думал, что Query Cache в MySQL работает «из коробки»
          Разве это не так?
          • 0
            Зависит от настройки «коробки», видимо — у меня не работал. Если работает — достаточно уточнить его объём из расчета общего объема памяти и нагрузки на БД.
            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                Думаю, что какие-то пекеджи с mysql меняют дефолтные настройки.
            • +1
              Бытует мнение, что буква Р в LAMP — это не строго PHP. Я вот полез поглядеть на оптимизацию Perl/Python, а оказывается это только PHP :(
              • 0
                Пардон. Я знаю, что это может быть Perl (а вот про Python в этом контексте никогда не слышал), но заголовок в любом случае потерял бы очень многое, если бы я начал уточнять.
              • +6
                Первое, что нужно оптимизировать в LAMP — менять Apache на nginx.
                • +3
                  Не менять. А ставить nginx перед Apache. Очень многие используют mod_php и не собираются отказываться по многим объективным причинам
                  • +3
                    Очень интересно услышать про объективные причины.
                    • +3
                      Можно и заменить, NGINX+ FastCGI — и отлично живем без апача, никаких неудобств не испытываем :-)
                      • 0
                        Можно. Но мы вот исторически привыкли к mod_php и ГОТОВЫМ сборкам софта «из коробки» Debian.
                        Дабы не разводить ходивар по поводу готовых дефолтных пакетов сразу отвечаю: нам так удобнее и поддержка готового обходится дешевле по времени (да и деньгам тоже)
                        • +1
                          apt-get install nginx php5-cgi

                          :-)

                          на самом деле на небольших проектах выиграш будет не заметен, но вот при большой посещаемости — отказ от Apache вполне оправдан.
                          • 0
                            Проблемы сразу 2: старые нджиниксы в репах и сложности с мод_рерайтом (надо переписывать правила)
                            • –1
                              нене
                              php5-cgi подвязанный к nginx убивает сам смысл nginx

                              Мы юзаем nginx в качестве фронта к ферме из апачей, до которых долетает только обработка php, вся статика отдается nginx'ом
                              • +2
                                Почему это убивает, обоснуйте свою точку зрения?
                                • –1
                                  nginx сделан для того, чтобы быстро и с минимальными затратами отдать статику, спроксировать тяжелый backend, а также освободить backend от медленных клиентов.
                                  Навешивание на него скриптов противоречит идеологии как таковой.

                                  P.S. Кстати — насколько я помню, cgi подразумевает отсутствие pconnect
                                  • +2
                                    Вы возможно имеете в виду CGI, а я говорил о FastCGI, процесс PHP запускается один раз и обрабатывает запросы nginx, в данном случае он и есть «тяжелый backend».
                                    • 0
                                      А php не жрет память при этом, не использует дисковые операции и не грузит процессоры?
                                      Я просто не в курсе, а оно может жить при этом на N* серверах?

                                      Я не говорю о том, что это совсем плохо. Это просто другой подход. Апач сам по себе или с помощью дополнительных модулей может дать много чего, недоступного ни nginx, ни light-httpd.
                                      • 0
                                        php FastCGI жрет меньше дисковых операций чем mod_php за счет того, что fvs кеш работает лучше, т.к. используется свободная память, которую занимал apache. Процессоры грузит примерно одинаково, плюс минус погрешность измерения. Жить может на N серверах легко, FastCGI это позволяет.

                                        Чисто по опыту, действительно есть 5-10% сайтов, для которых nginx не может дать аналогичную функциональность, например webdav/svn. Но остальные 90% все-таки переходят.
                                        • 0
                                          webdav вполне себе живёт на lighttpd. Неужели у nginx такого не реализовали?
                                          • 0
                                            Есть, но навскидку, для svn этого маловато будет.
                      • 0
                        Это не совсем так. Большого прироста производительности в сравнении с хорошо настроенным Апачем (к которому nginx стоит фронтэндом) не будет.
                        • 0
                          Сильно зависит от конкретной ситуации. Если памяти впритык, то отказ от Apache может дать прирост в 2-3 раза легко, только лишь из-за того что файловый кеш будет лучше работать, т.к. свободной памяти стало больше.
                          • 0
                            Кстати, ограниченная память это, похоже, ваш случай. Попробуйте.
                        • 0
                          Дело вкуса, но я предпочитаю lighttpd :)
                          • 0
                            А между тем большинство предпочитает nginx ;-)
                            • 0
                              Большинство предпочитает Апач. Но это же не показатель :)
                              • 0
                                А динамика роста — показатель?
                                • 0
                                  Динамика роста — это показатель динамики роста. Но не показатель того, что предпочитает большинство :)



                                  ИМХО, тут всё просто. Когда падает lighttpd (а такое бывает?), то просто пропадает сервер (а падающие php-fcgi процессы он сам поднимает прозрачно для пользователя). Когда падает fcgi в nginx — то юзер видит рекламное сообщение, что-нить типа “nginx Error 502 Bad Gateway”.

                                  Получется — халявная реклама. Название откладывается в голове. И когда админ дорастает до апгрейда Апача, он меняет его на то, что уже плотно сидит в голове :D

                                  (на меня не подействовало, т.к. я на Лайти пересел, когда nginx сильно устуал ему по возможностям, раскрученности, надёжности, SMP-производительности… :) )



                                  (на правах полночного бреда ;) )
                                  • 0
                                    Динамика роста в этом случае именно показатель того, что предпочитает большинство. Посмотрите как набирал объемы lighttpd: в январе 2007 года было всего 170 тыс сайтов. затем в марте их уже становится 1 399 000. Ага, кто-то крупный перешел. Но что мы видим дальше: за следующие 15 месяцев кол-во увеличивается до 1 532 000. То есть динамика в среднем плюс ~8 тыс сайтов в месяц. nginx же за это время имеет 119 000 сайтов в январе 2007 года и через 15 месяцев уже 2 125 000. То есть динамика плюс ~133 тыс сайтов в месяц, что в 16 раз быстрее ;-)

                                    Дальше аналогично: lighttpd делает следующий марш бросок, и в июле 2008-го сайтов на нем становится 2 942 000. Опять кто-то крупный перешел. И до сих пор это кол-во увеличилось всего до 3 046 000 (+20 тыс в месяц). А nginx растет себе ровно, за последние 6 месяцев он стабильно набирал по ~205 000 сайтов в месяц, то есть рос в 10 раз быстрее.

                                    Какой отсюда вывод — lighttpd весь свой вес набрал за счет двух-трех переходов крупных провайдеров, в то время как nginx увеличивает аудиторию постепенно, за счет массы. Следовательно, более массовый, а значит более популярный продукт именно nginx.

                                    Как мы видим, админов почему-то не пугают надписи «502 Bad Gateway». Которые, кстати, ни что иное как кривые ручки администратора. Правильно запущеный php ни со spawn-fcgi ни тем более с php-fpm.anight.org/ падать не будет.

                                    На правах рекламы.
                                    • +1
                                      >Динамика роста в этом случае именно показатель того, что предпочитает большинство.

                                      Так это прекрасно! С этой твоей формулировкой сегодня большинство пользователей предпочитают на десктопах Linux и MacOS. Ведь доля Windows достигла минимальной за последние лет 10 отметки, аж 89.5%! :D

                                      >Как мы видим, админов почему-то не пугают надписи «502 Bad Gateway».

                                      Я же выше писал, это не только не пугает, а, наоборот, раскручивает марку ;)

                                      >Которые, кстати, ни что иное как кривые ручки администратора.

                                      Ну, что могу сказать — получается, что масса очень крупных отечественных проектов содержит криворуких админов… Ибо я это знаменитое сообщение получал даже на Рамблере и, о чудо, на Хабре! :D



                                      А так — я ничего не имею против nginx'а. Более того, только приветствую его, так как конкуренция нужны всем. Но сам лично буду смотреть не на количество пользователей (а то бы выбирал Apache или, даже, скорее IIS), а на удобство и функционал под свои нужды. Да и на коммьюнити разработчиков, кстати. В таком деле проекту, который весь висит на одном человеке я доверять не люблю :)
                                      • 0
                                        Не надо передергивать факты. Мы изначально говорили кто популярнее, lighttpd или nginx. Но не Apache. Валяйте, сравнивайте динамику роста linux и macosx, чтобы иметь аналогичную картину. Но не Windows ;-)

                                        Тем не менее, ставлю вам плюс за интересное сравнение: действительно, linux и macosx, точно так же как lighttpd и nginx, как правило, выбирают осознанно.

                                        Что касается ошибок, не понимаю, почему вы именно на Хабре их не ожидали. Чем сайт лучше других? Или Рамблер? У людей есть определенные сложности с настройкой, но мне понятно откуда они берутся и как их решать, и кстати, я всегда помогаю, когда о них спрашивают.

                                        Вопрос выбора, в вашем случае обусловленного верой меня почему-то нисколько не волнует, я так себе и представлял пользователей lighttpd.
                                        • +1
                                          >Что касается ошибок, не понимаю, почему вы именно на Хабре их не ожидали. Чем сайт лучше других? Или Рамблер?

                                          Массовостью своей :) А Рамблер, кстати, ещё и тем, что это, насколько я в курсе, главный заказчик и потребитель nginx.

                                          >Вопрос выбора, в вашем случае обусловленного верой

                                          Да нет, не верой :) По вере я много лет назад Apache выбирал. А вот lighttpd — уже по ряду объективных факторов, которые и упоминал выше…

                                          А, или Вы про веру в контексте того, что в коммьюнити веры больше, чем в одиночку? Ну так эта вера тоже не на пустом месте формировалась :D
                                          • 0
                                            Но ваши выводы противоречат цифрам, которые я привел вышел.
                                            • 0
                                              Простите, но где Вы видите мои выводы, которые противоречат Вашим цифрам? Покажите пальцем :)
                                              • 0
                                                В том, что рамблер главный потребитель nginx. Это что, рамблер добавлял свои сайты по 200 000 в месяц последние пол года?
                                                • 0
                                                  Э… «Главный заказчик» != «главный потребитель».

                                                  Ладно, попробую погуглить, для убедительности… Ага, вот, сразу же:

                                                  ru.wikipedia.org/wiki/Nginx

                                                  «Разрабатывается Игорем Сысоевым с 2002-го года для компании Rambler и постоянно модернизируется. Осенью 2004 года вышел первый публично доступный релиз.»
                                                  • 0
                                                    > А Рамблер, кстати, ещё и тем, что это, насколько я в курсе, главный заказчик и потребитель nginx.

                                                    Ваши слова?

                                                    Я ответил, что Рамблер далеко не главный потребитель nginx.

                                                    То, что вы нагуглили никак не соотносится с темой спора.
                                                    • +1
                                                      А, понял. Да, написал машинально, а при перепроверке в глаза не бросилось, т.к. «и потребитель» было на другой строке.

                                                      В общем, имел в виду, что Rambler — это контора, которая фактически и выдвинула nginx.

                                                      А потребитель сегодня, вполне очевидно, что не главный.

                                                      Но речь-то шла не о том, а просто об известности такого потребителя.

                                                      Давайте, приводите примеры более именитых nginx-потребителей, оценим их :)

                                                      Для затравки того, раз уж в эту сторону пошли, то приведу примеры на стороне lighttpd: SourceForge.net, Youtube, Википедия, Imageshack.us, thepiratebay.org… :)
                                          • 0
                                            Да, кстати:

                                            >действительно, linux и macosx, точно так же как lighttpd и nginx, как правило, выбирают осознанно.

                                            Не смотря на то, что я сам сегодня убеждённый Linux'оид (и на практике — скажем, на этой машине у меня даже дуалбута нет), не могу Вашу формулировку применить к исходной :)

                                            1. Сознательный выбор Linux или MacOS ещё не означает, что все (или большинство) сознательно выбирающих выберут эти ОС. Я знаю массу отличных профессионалов в области IT, которые сознательно выбирают Windows :)

                                            Точно также многие сознательно выбирают не nginx или lighttpd, а apache или даже IIS.

                                            2. Изначально в формулировке речи не было о сознательности выбора :) Напомню: «А между тем большинство предпочитает nginx ;-)»

                                            Ни слова про осознанность ни в формулировке, ни по ссылке :)



                                            Я бы, всё же, сказал, что сегодня большинство _вообще_ выбирает apache или IIS. А осознанное большинство делится на неопределённые пропорции и далеко идущие выводы делать по ним, увы, нельзя.

                                            Но, наконец, не всё ли равно кто сколько чего выбирает? От того, насколько осзнанно выбирают nginx или lighttpd 3 млн. их пользователей, качество продукта не изменится :)
                                            • 0
                                              > 1. Сознательный выбор Linux или MacOS ещё не означает, что все (или большинство) сознательно выбирающих выберут
                                              > эти ОС. Я знаю массу отличных профессионалов в области IT, которые сознательно выбирают Windows :)

                                              > Точно также многие сознательно выбирают не nginx или lighttpd, а apache или даже IIS.

                                              Дополнение принимаю, но не вижу, как это противоречит тому, что я сказал.

                                              Я сказал «как правило», и имел ввиду именно это.

                                              Предлагаю завершить бессмысленную полемику.
                                              • 0
                                                >Я сказал «как правило», и имел ввиду именно это.

                                                Вот против этого я и возразил. Увы, но знакомые мне опытные и профессиональные IT-шники чаще выбирают Windows, чем Linux :)

                                                Более того, возьмём, например, ресурс linux.org.ru

                                                Кто туда чаще ходит? Ну, наверное, люди к Linux близкие. Смотрим на статистику, и что видим?

                                                top.mail.ru/oses?id=71642&period=0&date=2008-12-07

                                                54,5% Windows
                                                36,1% Linux
                                                8,5% Mac
                                                0,6% FreeBSD

                                                И даже не смотря на такие обескураживающие цифры я не делаю выводы о том, что профессионалы осознанно выбирают, например, Windows :) Я просто говорю, что ситуация неоднозначная, и выводы делать по тем обрывкам данных, что вокруг нет, увы, нельзя.

                                                >Предлагаю завершить бессмысленную полемику.

                                                Давайте :)
                                        • 0
                                          >php-fpm

                                          В портеже Gentoo нет. Соответственно, на боевом самообновляющемся сервере оно как-то отпадает :)
                                          • 0
                                            Все дело в вашей личной лени. Кто хочет — использует.
                                            • +2
                                              Нет, дело именно в автоматическом обновлении. ebuild я и сам могу написать для чего угодно. Но я, с тех пор, как Gentoo распробовал, испытываю отвращение к личному слежению за обновлениями используемого мною софта.

                                              Предпочитаю своё время тратить на более интересные вещи. Хотя бы на тот же Хабр :) А за обновлениями пускай компьютер следит, он железный.

                                              И поэтому, если на десктопе, я ещё могу себе позволить тестовый или нестандартный софт (сосбственно, у меня сотни пакетов таких), то на боевом сервере я буду держать только стабильный софт из базового портежа.

                                              lighttpd у меня автоматически обновляется уже более трёх лет. За это время проблем с обновлением не помню. Меня такой режим работы вполне устраивает :)

                                              Впрочем, ладно, я веду бессмысленный спор :) Вам нравится nginx, мне — lighttpd. Доказать что-то мы друг другу, похоже, не сможем (да и не особо хотим). Так что давайте просто жить дружно и дальше пользоваться тем, что нравится :)
                                  • 0
                                    это пока незначимое большинство. Но у nginx перспективы лучше.
                            • –5
                              Понимаю, что пахнет холивором, но
                              perl+fcgi+nginx+ опционально memached рулит очень-очень сильно.
                              • 0
                                Давайте какие-нибудь объективные показатели посмотрим, у вас есть?
                                • –1
                                  Объективных -нет, увы.
                                  Всё руки не доходят сесть и побенчмаркать
                                  • –2
                                    Ну не считая общеизвестных истин про мультиплексирование и акселерированное проксирование nginx-а
                                    • 0
                                      Ну, согласитесь, там не в разы быстрее Апача при обычных ситуациях. Фронтом nginx ставить можно и нужно, а вот вообще избавляться от Апача необязательно.
                                      • –2
                                        смотря что считать «обычной ситуацией»
                                    • 0
                                      У меня есть
                                      ab -n 10000 -c 1000 на bitrix под nginx+fastcgi-php не ложили систему в своп
                                      А на apache с mod_php — уложили

                                      Правда apache был prefork, но тем не менее — nginx+fastcgi экономнее расходуют память, чем apache prefork + mod_php
                                      • 0
                                        Расход памяти в экстремальной ситуации определяется в большой степени конфигом Апача.
                                        • 0
                                          рад за вас, но что делать, если вам не нужен tradeoff память-производительность, а нужно и то и другое?
                                          • 0
                                            Мне ни холодно ни жарко от излагаемых фактов, радоваться нечему :)

                                            Использовать nginx, конечно. Я же не против, просто на этом этапе надо уже понимать изложенное в моём посте как 2х2.
                                            • 0
                                              мы друг друга поняли %)
                                              Я тоже не спорю, что промежуточным шагом является, таки да, адекватная настройка того, что есть.
                                  • 0
                                    А чем вы эти графики красивые рисуете? Возможно их онлайн рисовать, а то у меня граф. интерфейса нет
                                    • 0
                                      Их рисует munin, для его работы GUI не требуется, он сразу рендерит веб-страницу с картинками.
                                      • 0
                                        Еще можно использовать collectd
                                      • 0
                                        тюнинг базы слабоват
                                        не помешало бы рассчитать обьем памяти под базу, количество открытых таблиц и тд и тп

                                        если используется innodb, то настройка кешей именно этого движка — дают бешеный прирост производительности
                                        • 0
                                          А у вас есть плагин mysql_queries? Что-то не нашел. Киньте ссылкой, если не сложно :)
                                          • 0
                                            У меня он в поставку входил… payalnik.com/mysql_queries
                                          • 0
                                            У меня он в поставку входил… payalnik.com/mysql_queries
                                            • 0
                                              10x! У себя не нашел просто :(
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                              • +1
                                                В тарифных планах хостеров выделенных серверов и VDS не копейки
                                              • 0
                                                А у меня что-то ни xcache, ни eAccelerator не заработали :( Тоесть сайт работает с пол часа, а потом перестает отвечать на запросы. Иногда правда до часа доходило. Пришлось выключить. Причем под кеш в обоих случаях выделялось от 128 до 256 Мб. Так и не понял из-за чего все валилось…
                                                • 0
                                                  C eAccelerator'ом у соседа такая же история. Причем что характерно apache валится в день примерно в одно и то же время. Пока не разобрались просто отключили.
                                                • 0
                                                  В phpmyadmin есть «Текущее состояние MySQL» — там статистика и даже советы на что обратить внимание.
                                                  Есть скрипт mysqltuner.com/mysqltuner.pl
                                                  Мне частенько помогает засунуть папочку из переменной tmpdir в ramdisk если Created_tmp_disk_tables растет а накрутка tmp_table_size не помогает. Только предварительно стоит прикинуть или промониторить какого размера дира там бывает.
                                                  В скрине делаю: #while [ 1 ];do du -s /var/tmp/mysql | awk '{ print $1}' >> /tmp/var_tmp_mysql.size.txt; sleep 1; done
                                                  Потом смотрю # sort -n /tmp/var_tmp_mysql.size.txt | tail
                                                  • 0
                                                    Жаль, но eAccelerator ощутимо нагрузку с продакшин сервера не снял. Сайтов около 100, активна половина. Load average как был от 1-2, до 5 ночью из-за Яндекса, так и осталось :( Mysql тоже оптимизировал советами, но результата особого нет…
                                                    • 0
                                                      А что вызывает такую нагрузку? Своп неактивен?
                                                      • 0
                                                        в топе больше всего активен mysqld, httpd тоже вылезает на запросы. К сожалению, nginx там пока не стоит — вот думаю заняться на выходных. Свап активен, вот картинко за сутки:
                                                        164310.ru/forpsi.swap-day.png
                                                        164310.ru/forpsi.load-day.png
                                                        • 0
                                                          Очень странно, что он такими пиками. Я бы прежде всего поприжал Яндекс в robots.txt, уменьшив скорость обхода сайта, уменьшил бы количество детей апача в конфиге, чтобы своп не включался, и посмотрел, что именно вызывает такую нагрузку.
                                                    • 0
                                                      Большое спасибо за то, что открыли для меня xcache.
                                                      Раньше пользовался APC, но в случае SMP xcache намного эффективнее!
                                                      • 0
                                                        Большое спасибо за то, что открыли преимущества xcache :) А неужели APC не умеет параллелиться?
                                                        • 0
                                                          Я не был в курсе этого, только вот прочитав конфиг xcache, об этом задумался и решил проверить.

                                                          Сейчас запрос практически любой страницы сайта занимает около 5-10 мс, страницы форума — ок. 25.
                                                      • 0
                                                        Ммм не люблю apache
                                                        Предпочитаю nginx + php-fpm

                                                        По оптимизации мускула:
                                                        Зачастую помогает перевод баз на InnoDB (ныне модно XtraDB, хотя я думаю с нашим железом мы разницы не увидим), особенно если tunung-primer показывает что-то типа

                                                        TABLE LOCKING
                                                        Current Lock Wait ratio = 1: 14

                                                        Но перед переходом рекомендуецца прочитать
                                                        http://www.mysqlperformanceblog.com/2009/01/12/should-you-move-from-myisam-to-innodb/

                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.