- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
kkc,
Вы правы!
Только это я наблюдал на прежнем впсе и админ уверял меня, что именно мы создаем такую нагрузку
/ru/forum/569900
Ну в чем тогда проблема то - единственно, что вы сами не могли прощупать, так это перегруз ноды по и/о, теперь вы знаете, что это именно ваши скрипты виноваты, дальше дело техники. А волшебной кнопки типа "ткнул и сразу получил ответ кто виноват и что делать" нету.
B каким образом это диагностировать?
B каким образом это диагностировать?
Вам просто нужно нанять толкового админа, который поможет вам решить вопрос. Здесь нельзя выполнить одну команду и сразу получить полный список того, кто виноват и что делать, а требуется комплексный анализ сервера.
насколько я успел вчера увидеть - тупила и статика. причем раздаваемая nginx, судя по заголовкам.
то есть отдача картинок - 5 (!) килобайт в секунду. если статика не отдается - то грешить на скрипты точно нет резона.
по идее картинка должны была попасть в кеш и отдаватья второй раз быстрее ибо не с винта. но этого не произошло.
а там на интерфейсе нет ерроров? отдача картинки из рамы должны была быть мгновенной - а оно все равно 5 кило в сек.
Например, в vz контейнере могут быть забиты сокеты - будет идентичная ситуация
B каким образом это диагностировать?
порно картинки с 18-летними надо поставить в Oracle, чтобы в любом случае открывались :D
по ходу нагрузка подает на IO винчестера...? ...у вас очень много файлов которые одновременно и все сразу отдаются через http????
===============
на счет скриптов:
manman,
спасибо за ответ!
насколько я успел вчера увидеть - тупила и статика. причем раздаваемая nginx, судя по заголовкам.
то есть отдача картинок - 5 (!) килобайт в секунду. если статика не отдается - то грешить на скрипты точно нет резона.
по идее картинка должны была попасть в кеш и отдаватья второй раз быстрее ибо не с винта. но этого не произошло.
а там на интерфейсе нет ерроров? отдача картинки из рамы должны была быть мгновенной - а оно все равно 5 кило в сек.
Это вопрос к мистеру nginx, а на прежнем впсe nginx не стоял, но iowait зашкаливал!
BasePelleta добавил 02-12-2010 в 12:24
Andreyka,
спасибо за ответ!
Так это вопрос к хостеру уже! Как это проверить, что "забиты"?
BasePelleta добавил 02-12-2010 в 12:27
rtyug,
спаибо за ответ!
Ну не с 18-летними, а 10 000 картинок по 16 кб. промоборудования! 100 хостов в сутки один и 800 хостов другой сайт!
BasePelleta добавил 02-12-2010 в 12:28
Картинки, что в базе будут храниться?
BasePelleta добавил 02-12-2010 в 12:30
А если поисковик забрел? Много это сколько?
BasePelleta добавил 02-12-2010 в 12:31
посмотреть логи: ддос/дос, флуди т.д.
анализировать исходники: померять скорость работы скриптов, потребление памяти, отлада, профилирование и т.д.
Подскажите команды!
глянь сюда _ttp://www.lexa.ru/nginx-ru/msg08507.html
nezabor,
благодарю за ответ!
Да, на это стоит обратить внимание!
Правда, у меня на старом впсе нгинкс не стоял, а иовейт аж зашкаливал!
Вот снова сегодня!
[ATTACH]78757[/ATTACH]