- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В рекламном кабинете Дзена обновился интерфейс дублирования публикаций
Всё стало удобнее и проще
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Приветствую!
Есть сервер с обычным HDD который параллельно медленно отдаёт много файлов большого размера. (типо видео-раздачи)
При 200 подключениях и скоростью отдачи 1 файла 20кб/сек, диск начинает тупить.
Возникает это понятное дело из-за бегания головки по всему диску.
Подскажите как правильно оптимизировать nginx под такую раздачу, я так понимаю нужен какой то кеш на подключение, чтобы он брал куски файлов большими порциями в память и как можно реже, например не ежесекундно, а раз в 10 сек.
Точно такая же задача есть и для php скрипта, он тоже отдаёт файлы постепенно считывая их порциями по 4кб без буферизации. Тут надо тоже что-то придумать чтобы головка диска не бегала так часто. Поделитесь опытом кто и как решал такие задачи.
SSD не предлагать.
Оптимизация обращений к HDD — задача больше для файловой системы, чем для nginx и, тем более, для php.
Ни nginx, ни php не знают, расположены ли блоки последовательно, или нет.
Рулить очередями и упреждающим чтением будет по-прежнему система и контроллер.
Мне кажется, попытка соорудить поверх этого "свой луна-парк" приведёт лишь к ухудшению показателей.
А если попробовать RAID?
А если попробовать RAID?
Сильно удорожит при зеркалировании. Либо пострадает персистентность при страйпе.
5-6 не сильно увеличит производительность при чтении. Особенно в операциях track-to-track. Хотя, прирост явно будет.
SSD почти полностью нивелируют track-to-track, но "SSD не предлагать" :D
Сейчас RAID1, скоро будет RAID10, что конечно увеличит кол-во соединений раза в 2, но этого мало. Для nginx нашёл только output_buffers, который должен помочь, попробую покрутить.
raid10, access_log off, https://easyengine.io/tutorials/nginx/open-file-cache/