27 октября 2015 в 1:21
Народ, приветствую.
На сервере установлен Дебиан 6, апач. Сервер год или больше не обновлялся. Есть нужда поставить nginx как фронтэнд к апачу. Обновлять сервер не хочется - не моё хозяйство. Сисадмин с меня вообще почти никакой, но я учусь 
Вопрос: насколько это плохо - написать apt-get install nginx не сделав apt-get update apt-get upgrade?
Комментарии
это как машину бросить на улице с открытыми окнами, заботливо оставив ключи на консоли
nginx мало поставить, надо будет это дело настраивать, и конфиги httpd править тоже
просто снимок диска предварительно сделай и дерзай - http://habrahabr.ru/post/120814/
некоторые линуксы по несколько лет не обновляются и прекрасно работают, это не виндовз.
"Безумству храбрых поём мы песню!"
dd? да там как-бы особо некуда, места свободного меньше чем занятого
на другой.
это всё понятно, но меня щас исключительно практический вопрос интересует чтобы ничего прям щас не сломалось из-за того что не обновлено.
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/ploop19111p1 79G 43G 33G 57% /
tmpfs 8,0G 0 8,0G 0% /lib/init/rw
tmpfs 8,0G 0 8,0G 0% /dev/shm
некуда
не без хотя бы бэкапа не советую.
http://itman.in/disk-image-dd/
другой жесткий/флэшку или сетевой подрубай.
я сам себе не советую. ссу. У меня на флопсе так хорошо - нажал образ создать в панели гипервизора, 10 сек - и хоть убей его, 10 мин и всё как было.
да это впс в эстонии..
и неужели там нет кнопки сделать снапшот?
если нету, жди сисадмина (за одно пусть всё обновит), не рискую завалишь сервер.
а с чем связана необходимость установки nginx?
Сервер очень мощный (6 ядер, 32Гб RAM, диск в 6 раз быстрее моего флопса). Там крутится 1 сайт нетяжёлый на umi cms, и он не "летает". Вроде мускул и апач подкрутил, стало чуть лучше, дальше смысла нет, а статику всёравно медленно отдаёт. 3.5-4.5 сек страничка грузится. При том что сервер совершенно не загружен. Load average 0.02 0.01 0.00
та там такой сисадмин, шо его лучшеб не было - сам не обновляет и людЯм не даёт. Оттого и вопросы.
Пока не знаю. Я так понял, что она очень не у всех есть. Сервак у FastVPS. Больше пока не знаю, мне пока тока рута дали.
тогда просто попросить, пусть сами образ сделают, а может они и делают.
всё таки советую сначала оптимизировать связку кмс с апачем.
хотя может ты и прав (нужен нгинкс) http://lib.clodo.ru/cms/umicms-os-debian.html
http://wiki.umisoft.ru/%D0%9A%D1%8D%D1%88%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%...
мне это понравилось: "Пользователям версии 2.8.3 (и выше) предлагается новая экспериментальная функция кэширования через nginx. Наши исследования показали ускорение работы сайта до 100 раз и более. "
я уже вроде подкрутил кое-что.
StartServers 2
MinSpareServers 6
MaxSpareServers 12
MaxClients 60
MaxRequestsPerChild 3000
что там ещё крутить? Сервер без нагрузки, должен просто работать.
ты прав, нужен нгинкс.
а наши исследования показали что у этой юми в системных требованиях стоит php 5.4 который кончился месяц назад. А на 5.5 оно не устанавливается.
отложили до выходных. Сервак боевой всётаки.
А мне предлагают шареды и 256 метровые впски ускорять,плакать хочется
ускоряются?
У меня началось всё с ускорения сайта, тыж программист. Всю излазил эту юми волшебную. Гляжу - вроде сервер ненастроенный. Так и есть - его админ левой пяткой настроил (т.е. поставил lamp) когда-то да и бросил. Работает - не трож. Еле рута выпросил. Я никогда особо этим не занимался, а тут интересно стало, как так - такой сервер большой, а страница 4 секунды грузится.
Зато открыл для себя чудо модуль для апача mod_pagespeed, работает, почти на секунду удалось сократить. Но отдавать лёгкую страницу 3 секунды при таких железах - всё равно помойму не дело.
с этой Юми волшебной ещё проблема что её не перенесёшь на другой сервак посмотреть - лицензия к домену привязана. И что ещё мне не понятно - там в админке Юми есть показометр производительности. Типа считает сколько раз сгенерится пустая страница за секунду. Так вот у товарища сервер раза в 4 хуже, тоже Юми стоит, показометр показывает 15-16. А тут 4-5. Но у товарищза стоит nginx. Но страица-то пустая генерится. Куда копать - ума не приложу. Придётся исходники читать этого показометра наверное.
а чем то кешируется? (APC)
нет, голый апач
Правильно, в данном случае, будет сделать:
apt-get install nginx
Первая команда безопасна, т.к. обновляет только список пакетов.
Без неё может просто не найтись на сервере пакета с nginx старой версии.
На не нагруженном сервере, даже не настроенном, после настройки, скорость загрузки страницы, будет отличаться чаще всего не более чем на десятки или даже единицы процентов...
Вот под нагрузкой он бы тормозил, тогда да, скорость могла бы заметно измениться.
Т.е. не оптимальными настройками куда проще испортить не скорость загрузки на клиенте, а устойчивость сервера к нагрузкам.
Пример с установкой nginx: apache раздаёт статику не сильно-то медленнее nginx, просто на это требуется больше ресурсов, и если свободных ресурсов, как в вашем случае много, вы вообще можете не заметить разницы...
Советую, всё же, заняться свои профессиональным делом, т.е. разбираться что с сайтом, собственно. А клиенту порекомендовать поискать толкового сисадмина, объяснив, что разработчик его не заменит, и что это две совершенно разные специальности.
90%, что проблема в пресловутой UMI, которая то ещё Г, похлеще битрикса. Чтобы не гадать, возьмите xhprof и посмотрите, а что собственно там так долго работает.
спасибо, это понятно.
было 15 сек иногда на этом. Вот грузится страничка, статика отдаётся-отдаётся, и вот один файл как-бы подвисает, каждый раз разный, картинка какая-то, и ждёшь его до 15 сек. Как чуть добавил количество серверов апача - вроде прошло.
спасибо, но мне пока интересно. Вы вот, к примеру, сайты делаете?
Борис правильно говорит, настройка это дело специалистов, наше дело копирнуть их в удобный момент, следить за жизнедеятельностью сервера, по большому счёту - лучше отдать спецу на мониторинг, в месяц это небольшая сумма, а головных болей убирает много, как и седых волос в перспективе.
гонял xdebug в режиме профилировщика на локалхосте (первый раз в жизни), честно - ничего не понял. Понял, что чтобы понять его данные надо разбираться в UMI, чтобы понимать что это за функции, с отладчиком лазить не один день, понимать архитектуру этой UMI. А мне эта UMI не настолько нужна чтоб думать столько про неё - товарищ попросил глянуть.
Костян, лучше ваще чтобы всё спецы делали. А если не спец - живи спокойно, огород копай, таксуй... нафига этот головняк
Не вопрос. Но сам станешь спецом когда в спарке тебя носом тыркать будут, да на экране разжёвывать непринуждённо, и если зрительная память хорошая, возьмёшь значительно больше, чем кто-либо будет предполагать.
пошёл искать спарку.
Да тут не ngnix, тут varnish напрашивается с memcached/redis.
И mysql добавить буферов/кеша.
Эх, столько рамы без дела пылится.
Использование Varnish, в большинстве случаев, это не более чем дань моде, а ещё чаще вредительство. Он нужен в очень узком спектре задач, и даже там, не всегда является самым удачным решением.
В mysql надо не добавить кеша/буферов, а корректно его настроить под конкретную задачу.
Может keepalive выключен? Или действительно была нехватка процессов апача... Испортить, конечно всё можно, просто случаи проблем, именно со скоростью загрузки страницы, сравнительно редки.
Я делаю сайты иногда(правда больше оптимизирую), но я в этом разбираюсь весьма неплохо, как и в администрировании. И безусловно веб разработчику надо знать окружение, в котором работают его творения, но в данный момент, у вас нет знаний ещё, чтобы нормально настроить это окружение, и вопросы на форуме не решат эту проблему. И тем более, плохая идея на продакшене у клиента что-то пытаться методом тыка оптимизировть.
Это больше от слабого владения инструментами, чем от слабого знания UMI. Разберётесь как работает профайлер и как его данные интерпретировать, и вам будут не так страшны незнакомые скрипты. Можно вообще не знать, что за скрипт работает на сервере, и по результатам работы профайлера сказать, где узкие места, и какие части кода надо смотреть/переписывать.
По времени - да, это процесс не минутный.
keepalive включён. Да, после добавления процессов "зависания" файлов прошли.
это не совсем клиент, знакомый товарища, товарищ делал тому сайт, и попросил помочь разобраться, отчего так медленно. Бесплатно/за пиво.
ну как тыка. Я ж читаю подряд всё по теме, даже документацию!
скорее всего да, я первый раз его использовал, но надож когда-то начинать.
знаний действительно не много, но откуда им браться, если не решать практические задачки? Читать "впрок" я не умею, проверено.
Это и есть методом тыка. Чтобы было иначе, надо иметь систематизированные знания в области поиска проблем с производительностью, и правильно подходить к этой задаче. У вас их нет, и чтение всего подряд не поможет - не сможете оценить, что из возможных решений нужно применить в данном конкретном случае и как.
Как вы берёте оплату, не важно, хоть борзыми щенками, но это клиент с проектом в продакшене. В вашем случае, надо было ему дать полезный совет, обратиться к тому, кто может нормально решить его проблему. Это было бы ответственным подходом.
Необходимо систематически учиться, иначе будут не знания а повторение различных howto.
Решать практические задачки можно прямо на своём компе, используя виртуализацию.
машине сам тех. обслуживание проводишь?
это россия детка, здесь на одного нормального, куча кидал.
) Слёту прочитал "ни одного нормального" - думаю нифига Гедеон с утра злой чот ))
раз такая пьянка. а php7 кто-нибудь тыкал из любознательности? активность вокруг него нормальная
Не прокатило - не только техобслуживание, но и ремонт. Хобби у меня такое.
Позанудствую...
да вот что-то мысль такая прокралась, вот и спросил
на d.org сейчас все на ушах, помониторил багтрекер, тесты то проходит, то не проходит (ошибки сегментации), кодеры php не догоняют откуда такое поведение. вот прямо сейчас идет обсуждение. друпалеры переживают, ибо если вопрос не решится, D8+php7 на production юзать палево. хех, если не станет лениво, попробую на DO поднять окружение, поставить D8 и выполнить тесты. ибо по производительности должна быть сказка.
неа, я сознательно здесь написал
так наоборот прокатило, делаете, но Вы не автослесарь. в своем сервере тоже самое. когда на поток, каждый со своей конфигурацией, то да согласен надо быть спецом, а изучить свой сервер под свою задачу вполне возможно.
не подрезайте крылья и не переоценивайте самого себя. он Вас не дурнее.
Стоит потыкать? В плане друпала?
А вот я Борису не скажу, что я хотел ему сказать
а он веткой мне кажется ошибся, тут про php оффтоп начали http://www.drupal.ru/node/125792
У меня тоже хобби линуксовое. Объединяемся
Да, скорее инженер автомобилестроитель по образованию, как ни странно.
И я, к тому же не занимаюсь ремонтом машин клиентов.
Крылья я не подрезаю, я говорю о том, что учиться на сервере клиента, даже делая работу за пиво, по меньшей мере некрасиво. А не о том, что не надо учиться.
Мало того, то, что подавляющее большинство веб разработчиков не имеет почти не малейшего представления о том, как работает окружение в котором запущены их "творения" меня обычно сильно огорчает. И я всячески приветствую расширение их кругозора, в частности, отвечая на вопросы на этом форуме.
Борис, а скажите пожалуйста, раз Вы не учились на сисадмина в Вузе, стало быть Вы занимались самообразованием. Т.е. читали книжки, настраивали вируальные машины, тестировали их под виртуальной нагрузкой, придумывали виртуальные проблемы, реализовывали их, а потом решали. Просили аникейщика настроить вам виртуальную машину нарочито плохо, покупали Юми, или Битрикс, просили говнокодера сделать нарочито тормозной сайт. И оптимизировали. И вот сам вопрос теперь: много у Вас времени ушло на это? Ну примерно? Полгода, год, мож больше? Прежде чем Вы сами себе выдали диплом и сочли себя готовым к боевым серверам и деньгам клиентов?
Или может всё было не так, и Вы родились с этими знаниями? Я просто прикидываю, как мне, грешному, жить дальше.
К сожалению, когда я учился, у нас было примерно никак с образованием в этой области. И если программирование ещё как-то изучить было возможно, то системное администрирование только самостоятельно. Также, было плохо и с виртуализацией, поэтому эксперементировать приходилось на реальном железе. Да и с литературой было отнюдь не всё в порядке, прямо скажем.
Поэтому всё началось с изучения FreeBSD Handbook и подобных ресурсов. Ну и в дальнейшем Gentoo, т.к. такие вещи дают хорошее понимание того, что там "под капотом", что совершенно необходимо в дальнейшем.
Вообще, между началом моего увлечения unix системами, и работой в этой области, наверное, лет 5. Естественно, если задаться целью изучить именно системное администрирование и выделить для этого достаточно времени, уложиться можно в куда меньшее время, особенно сейчас, когда информация куда более доступна, и есть различные курсы, в частности онлайн.
Если интересно именно администрирование, то можно начать со сборки веб сервера на Arch или Gentoo, это даст немало знаний того, как оно работает, и на выходе, через довольно немалое время, правда, удобное окружение для разработки, которое поможет вам в основной работе. А также понимание, ваше-ли это вообще. Ещё лучше, конечно, добавить какие-нибудь курсы, например от RedHat.
Проверить свои знания, можно по вопросам сертификационных тестов от того же RedHat, кстати, типа RHCSA, вопросы гуглятся. Не обязательно проходить официальный экзамен, но получить итоге сертификат - большой бонус, если решите заняться серьёзно администрированием в дальнейшем.
Подготовившись подобным образом, вы уже будете иметь базис знаний, который позволит вам более-менее начать понимать, что вы делаете, и зачем. И минимально оценить свои силы, прежде чем браться за ту или иную работу, что очень важно.
По поводу же оптимизации кода - вы ведь разработчик? Тогда у вас уже есть, вероятно, запас проектов которые вы разрабатывали, и на которых вы можете для себя позаниматься оптимизацией, познакомиться с инструментами и посмотреть на результаты. Естественно в своём окружении для разработки а не на продакшен серверах.