- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Приветствую!
Вообщем мучает меня уже давно странная ситуация.
Есть сервачёк (с debian 6) от ДЦ leaseweb, 2 диска без рейдов.
На одном система и сайты sda, на другом бекапы sdb.
Сайты бекапятся каждую ночь на sdb, никакой нагрузки при этом на систему не оказывая, всё отлично, LA 2-3 - не зашкаливает.
Далее производится еженедельное закачивание бекапов на удалённый сервер. Делается это с удалённого сервера путём подключения через wget по FTP протоколу. (wget так умеет)
Во время подключения в течении первых 2-3 минут рабочий сервер с сайтами умирает, LA 50-100.
Вопрос, Скажите какого фига при обращении к диску sdb, например /sdb/backup.tar, умирает главный диск на котором система и сайты - sda?
Анализировал через atop, iotop, понять никак не могу, sdb нагружен на 5%, sda на 100%, процессы никакие не выделяются особо. Присутствует ощущение что при обращении по FTP для скачивания, бекап сначала копируется на sda или его swap или ещё куда-то на этом диске, и лиш потом начинается закачка.
А теперь главный фокус, на другом сервере с software raid настроенном одинакого и одинакого нагруженным, такое же скачиваени проходит вообще незаметно!
Зарание спасибо, за любые предположения почему так происходит.
В это время включите htop и посмотрите своп.
Диски смартом давно смотрели? И конечно зря без рейда, если что - разворачивать долго =(
Ну во первых юзать фтп и через него гонять большие объемы - это както по извращенски.
Во вторых изза настроек фтп - вполне таки архив может качаться сначало на первый диск (на котором система).
Поставьте лучше lighttpd на свободный порт (чтоб апачу на 80 не мешать), настройте доступ по ip и качайте вгетом как и качали. лайти статику отдает не хуже, а по мне так кажется и лучше, чем nginx
В это время включите htop и посмотрите своп.
Диски смартом давно смотрели? И конечно зря без рейда, если что - разворачивать долго =(
atop тоже самое, а то и лучше, большого использования свопа не замечал, в районе 200мб часто используется, буду смотреть на этой неделе как пройдёт...
диски в отличном состоянии по показателям смарта
foxi вот честно, я могу только на ФТП думать, но зачем ему перед закачкой копировать на другой диск, и какие для этого могут быть настройки? На сервере proftpd.
lighttpd по разным причинам не вариант.
foxi вот честно, я могу только на ФТП думать, но зачем ему перед закачкой копировать на другой диск, и какие для этого могут быть настройки? На сервере proftpd.
загуглите "виртуальные директории proftpd", может они монтируются 🤪
да и вообще proftpd сам по себе тяжелый, при работе расходует много ресурсов.
lighttpd по разным причинам не вариант.
это по каким же причинам?
Покажите топ при таком la сюда
foxi, например, нужно пакетное решение без проведения настроек.
Andreyka
Дело в том что это не всегда так, но это всегда когда начинает перекачку бекап, именно первые минут 5. Пробовал вчера сделать такую же ситуацию но видимо общая нагрузка на диск была слишком мала, и LA был максимум 7.
В топе я ранее ничего необычного не замечал, LA большой потому что апачи видимо ждут первый диск. (общий CPU свободный был) Но вопрос остаётся, почему бекап который качается со второго диска может влиять на первый? (на втором диске только бекапы)
Проверьте логи от фтп сервера. Может они переполнены или лежат на битых/пендинг/долгочитающих секторах sda, за счет этого бывает тупняк на ровном месте.
А вообще лучше сервер "показать доктору".
Логи ротируются, файлики новые открываются, поэтому не может лежать на битых секторах, здоровье по смарту нормальное, но мысль была уже просто сменить сервер.
Также сейчас подозрение на то что proftpd при начале отдачи большого архивчика, пытается не малую часть засунуть в память, память и так всегда почти занята, отсюда вероятно идёт в swap. Сейчас пробовал, вроде как скушало дополнительные 200мб, опять же кто скушал не понять, может это апачи которые подвисли в ожидании и им потребовалось больше памяти... вообще лажа полная и проблема эта уже около года надоедает 😒
У Вас /tmp наверняка не слайсом сделан, а просто директория на sda. Поэтому нагрузка перемещается с sdb на sda. Но это всего лишь безпочвенное предположение и игра в угадай мелодию.
А вообще лучше реально показать top/iotop на момент нагрузки. Даже если она всего 7, все равно покажите. Лидера по нагрузке сразу видно будет.
Без снимка top ничего не подскажу