чюваки, есть ли среди нас гуру администрирования веб-систем? мне нужно понять где у нас косяк в настройке системы на nginx+php+mysql. Отзовитесь!

80 Responses to чюваки, есть ли среди нас гуру администрирования веб-систем?

  1. Xxxno:

    ты напиши чего хотел-то.

  2. RatFcuk:

    рассказывай, можно с конфигами

  3. Naref:

    В mysql, точно тебе говорю!

  4. OdaSport:

    короче, есть у нас http://www.dunlop-tire.ru, который странным образом медленно отдает даже статичный контент из кеша. динамические запросы он отрабатывает ооочень медленно, что не здорово.

    стоит он у нас на VDS на хостинге имени 1GB.ru. VDS оборудован 4096 Mb, 10664 mHz, 80 Gb чего для нормального функционирования одного сайта за глаза.

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

  5. Naref:

    Вообще-то у вас нет dunlop–tire.ru.

  6. OdaSport:

    да есть, перезапускали.

  7. Naref:

    Как-то вы там бохато перезапускали:

    $ host http://www.dunlop–tire.ru 8.8.8.8
    Using domain server:
    Name: 8.8.8.8
    Address: 8.8.8.8#53
    Aliases:

    Host http://www.dunlop–tire.ru not found: 3(NXDOMAIN)

  8. OdaSport:

    витеньке с парсером привет. руками напиши домен и все будет.

  9. Naref:

    А.

    Лицорука. 8 с гаком мегабайт на страницу.

  10. Xxxno:

    после такого туда и идти не хочется.
    но любопытство пересиливает!

  11. OdaSport:

    таковая се ля ви нашей сложной жизни. история много весит, да. зато красиво.

  12. Xxxno:

    надеюсь эта байда статикой nginx’ом отстреливается?

  13. OdaSport:

    это самый большой спрайт на этом сайте.

  14. OdaSport:

    любая страница отдается статикой из кеша.

  15. OdaSport:

    о господи, вот фор?

    Linux Nix Web Development - http://linuxoids.org/ размер 388x32, 11.43 kb

  16. Xxxno:

    впрочем, не надо — видно, что быстро.
    (7.78 MB/s) — “pic-history-wheels.png” saved

  17. Naref:

    Да там 304 вылезает, так что ок.

  18. RatFcuk:

    хм, ползал на сайте ща, все быстренько

  19. OdaSport:

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

  20. Xxxno:

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

  21. RatFcuk:

    поставить мониторинг,хотя бы Munin
    загнать тест с другого серванта или loadimpact.com
    смотреть как себя что ведет
    сайт, судя по всему в плане сложности выборок и т.п., легкий
    или какая нить жопа с базой или настроено все через…

  22. RatFcuk:

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

  23. OdaSport:

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

  24. RatFcuk:

    реально ща проще скинуть в личку ssh доступы и уже по факту глянуть что как и потом будет понятно что делать надо. даже если с нуля пеерставить nginx+apache+varnish+sql — работа на час максимум.. 30-50$

  25. Xuagreen:

    1. Дамп всех запросов, профайлинг, explain. Ебически медленные запросы из-за ORM, которым ничего не помогает, переписать руками без ORM.
    2. Профайлинг PHP — откроет глаза на остальные проблемы.

  26. RatFcuk:

    этож что за запросы такие должны быть, что бы посещаемости ниже плинтуса так тормозить по мелкой базе? или ORM самопис быдлокодера

  27. Xuagreen:

    проебал один индекс и всё, пиздец. Потому не надо задаваться вопросом «что за запросы такие?», а надо брать в руки профайлер, эксплейн и ебашить!

  28. RatFcuk:

    да даже при фуллскане.. там товаров не более 2-3 тыс… вся база в памяти помешается же

  29. Xxxno:

    а если там 32 джойна в запросе?
    slow log + explain

  30. Xuagreen:

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

  31. RatFcuk:

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

  32. OdaSport:

    дяденьки, с запросами и с программированием все хорошо.
    это не первый наш проект на этом движке, поэтому там все отлажено и проверено тысячу раз. http://www.etoya.ru трудится именно на нем, а там и посещаемость, и структур данных, и самих данных на пару порядков больше, и этот сайт не вызывает особых трудностей у серверов — он всего на двух работает. так что все рассуждения про косяки в коде можно оставить в стороне, правда.

  33. OdaSport:

    я не программер

  34. RatFcuk:

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

  35. OdaSport:

    это вдс, поэтому там винта не очень много в прямом доступе

  36. DniMilk:

    ну если проблема не в оптимизации кода/бд, то тогда дело в disk/network/memory I/O. Другого не дано. Пробегитесь любым бенчем по ним.

  37. OdaSport:

    внешний мониторинг подключен не так давно, но статистики пока маловато. А вот чтобы предъявить претензии хостингу, мне хочется исключить возможные проблемы в конфиге, которые наши админы могли упустить. добуду конфиги — запощу. внутрь пустить, к сожалению, не сможем

  38. OdaSport:

    в файловой системе, точно тебе говорю,)

  39. DniMilk:

    какие проблемы в конфиге если вы говорите «все отлажено и проверено тысячу раз». прогоните быстро тесты. или хотя бы посмотрите по-быстрому кто отжигает в atop. может из хардварного рейда винты повылетали, ОС-то об этом не знает.

  40. RatFcuk:

    самый простой вариант с другого сервера прогнать ночью тест по загрузке статики большой (канал), маленькой (скорость диска в iops) и страницу (динамика апача и т.п.) + страницу «статичную» (не каталог).. будут 4 цифры..

    если не напьюсь, то в 12 часов ночи могу прогнать тест нагрузочный

  41. Xuagreen:

    Так, товарищ, я чё-та не пойму — тебе проблему починить или где?

    ЗАПУСТИТЕ УЖЕ НАКОНЕЦ ПРОФАЙЛЕР!

    Этим нехитрым действом вы сразу найдёте где косяк: в коде, в базе или в hdd хостера. Пять сраных минут работы программера, а ты тут уже сутки доказываешь, что всё зашибись. Раз зашибись, значит и проблемы нет, пост закрыт.

  42. RatFcuk:

    если это все, то статика не отдается nginx
    число соединений можно увеличить в 10-20 раз

    есть стата по нагрузке (хотя бы munin)?

  43. Xxxno:

    ого, с чего ты взял, что у тебя статика nginx’ом отдается?
    у вас бедный бэкенд каждый раз эту четырехмеговую фигню ворочает.

  44. OdaSport:

    дополнил файлы обработкой статики. в самом низу, тот же адрес

  45. RatFcuk:

    не обновилось или не добавили.

    в идеале должно быть нечто (у меня апач, так что бэк такой)

    location ~* ^.+.(jpg|flv|swf|jpeg|gif|png|ico|css|zi p|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt |tar|wav|bmp|rtf|js)$ {
    root /www/ ;
    access_log off;
    expires max;
    add_header Cache-Control public;
    error_page 404 = @fallback;
    }

    location @fallback { #раз нихера нет, то лезем уже …
    proxy_pass http://127.0.0.1 ;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_send_timeout 30;
    proxy_read_timeout 30;
    proxy_set_header Connection close;
    proxy_pass_header Content-Type;
    proxy_pass_header Content-Disposition;
    proxy_pass_header Content-Length;

    }

  46. Naref:

    За каким хреном в такой схеме @fallback?

  47. OdaSport:

    о, парсер.

  48. OdaSport:

    location ~* ‘^/.+.w{2,4}(?

  49. RatFcuk:

    порой не все картинки файлами валяются у меня, хотя я не написал как из мемкэша их достаю тогда уж…

  50. Naref:

    Хм. А вот, кстати, зачем?

    Мы в свое время в конторке прогоняли тесты — так вот держать статику в мемкэше/рамдиске получается всего на 1-2% эффективнее, чем просто с диска отдавать.

  51. Xuagreen:

    а если увеличить дисковый кэш, то эффективность будет 0.

  52. Xxxno:

    не забывай, от диска еще зависит.
    если какая-нибудь ебучая полка, подключенная по iScsi — это одна цифра, а если sas встроенный — совсем другая.

  53. RatFcuk:

    ага, а если это ебучий nas в сети хостера в облаке с гарантией 450iops на слот, а отдаем кучу статики, то…

    //todo надо будет сравнить файловый кэш NGINX и просто отдачу статики с включенными кэшами системы и с нехваткой памяти

  54. Naref:

    Дисковый кэш — динамический в современных системах. Микроскопический прирост производительности обусловлен отсутствием fopen/fclose 🙂

  55. Naref:

    Если у тебя есть nas в любом виде — то за идею отдавать статику напрямую с него нужно в голову гвоздь вбивать.

  56. Xxxno:

    не могу поспорить со столь очевидной вещью.

  57. Xuagreen:

    динамический, но управляемый (: А на рамдиске тоже есть fopen. Хотя чё мы тут из-за процента спорим? На погоду точно не влияет как ты его ни крути.

  58. Naref:

    «Неаккуратненько как-то» ©

    🙂

    И, да — ispmanager должен гореть в аду!!!

  59. Xuagreen:

    у нас статика на насе. Но у нас пользователи размазаны по сервакам по всему миру и статику отдают локальные прокси с наса. Правда перед этим они эту статику складируют к себе, конечно же. Нас используется как единая точка заливки контента, а оттуда уже всё разлетается по проксям on-demand, кешируется и впредь отдаётся с локального винта.

    Я кагбе согласен с тобою про гвоздь, но перед вбиванием надо бы удостовериться, что его надо вбивать (:

  60. Xuagreen:

    наверное это к счастью, но я не знаю, что такое ispmanager (:

  61. Xxxno:

    а чем синхронизируете?

  62. Xuagreen:

    такие вопросы уже не ко мне, я программер. Моё дело знать, как это касается меня, а как оно внутри работает — это надо в админы переквалифироваться (:

  63. Xxxno:

    слушай, а спроси их по-дружески, и можно постом мне потом.
    мне вот тут предстоит дикая заморочка с синхронизацией контента, а я надежнее rsyncfs/sshfs ничего не знаю. может прогресс уже куда продвинулся этом плане?

  64. Naref:

    * завидует *

  65. Naref:

    Так вот именно так и надо делать. nas — медленный и надежный, и куча фронт-эндов с nginx и proxy_store. Дешевых, тупых, и нерезервированных — которых не жалко.

  66. Xuagreen:

    вон тут про proxy_store пишут, скорее всего так и есть — всё средствами nginx. У нас не любят добавлять дополнительные сущности без острой необходимости. Будет время — уточню. Если не забуду (:

  67. Xxxno:

    прокси сторе — способ хранения, а не синхронизации

  68. W0dblack:

    иди к нам на fornex.com — поможем с настройкой/установкой/переносом

  69. OdaSport:

    В общем, как я и говорил, тормозит файловая система. Наш замечательный хостинг потратил две недели на устранение проблемы, но так до конца ее не решил, но скорость заметно подросла, что, конечно же, радует. Попробуем сейчас перелезть с OpenVZ на HyperV, надеемся, что станет лучше. Если не станет, переедем к другому хостеру.

  70. DniMilk:

    А как определили, что фс? Какими тестами пользовались?

  71. OdaSport:

    ну там сразу много вопросов было. пхп компилировался слииишком уж долго, обновление через свн занимало неприличное время и так далее. Потом мы втупую выключили сайт, чтобы снять внешние раздражители и выполняли прямой запрос к мускулю типа show full processlist. Мускуль давал ответ от.002 до 12 секунд на пустом сервере. При этом запросе как раз изпользуется фс, что в свою очередь говорит о проблемах именно с ней. Гораздо больше было мороки с сапортом, который упорно слал нас нахуй и говорил, что это проблемы наших админов. Но они нашли проблему и исправили. Сейчас все равно будем слезать с openvz и смотреть на быстродействие hyperv.

  72. DSLNo:

    Прошу прощения, но вы какие-то долбоебы, право слово.

    1) Проблема с ФС видна сразу по статусу D в процессах
    2) OVZ одна из самых быстрых систем виртуализации засчет того, что системой виртуализации ее можно назвать с большой натяжкой, это больше chroot.
    Hyper-V использует режим полной эмуляции, из-за этого скорость дисков больше чем на OVZ не будет. В том же qemu, если не работать с нативным драйверами, скорость дисков и нагрузка на dom0 — просто пиздец, благо есть virtio и gplv. Начиная с 25 ядра появились cgroups и имеется возможность залимитить клиентам иноды и общую пропускную способность.
    3) Я попросил пароль на сервер и предоставил отзывы — Вы даже не соизволили ответить.

  73. DSLNo:

    ну и напоследок, 1gb.ru один из самых дешевых хостингов с ~50К доменов по 1stat, а их техдир http://vkontakte.ru/id88910541 (простите за вконтактик) сказал как-то с ухмылкой:
    «Мы от mango office отказались, потому что слишком дешево. А то что дешевое хорошим не бывает, я могу сказать уверенно»

  74. DniMilk:

    я юзаю OVZ и не подтверждаю проблем с ней

  75. DniMilk:

    кинь отзывы сюда, чо уж

Добавить комментарий