- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
AGHost, смысл в получении уверенности в сохранности данных. Спешка тут не нужна.
Некоторые считают, что нагрузка на диск такая же пластичная как на процессор. Однако, процессор может почти моментально переключиться и начать обрабатывать более приоритетную задачу. И все видели как это работает. А жесткий диск, если начал перемещать головку, то уже не может остановиться и начать перемещать в другом направлении. Единственный выход - не давать слишком оптимистичных заданий. Ограничить скорость синхронизации.
Если у вас все работает - вы диски не нагружаете полностью.
Я бы тут вообще отключил синхронизацию, сделал бекап и разбирался что там происходит. Были ситуации, когда при синхронизации диск умирал и массив разваливался.
Если у вас все работает - вы диски не нагружаете полностью.
Это не имеет ничего общего с нашими услугами, я делился сугубо личным опытом работы с софт-рейдом.
допустим, atop покажет колонку busy. И так ясно что она у вас к 100% приближается,
Вы правы. Под пиковой нагрузкой 60-80%
Завтра попробую сделать тюнинг системы. На сервере только php-fpm и nginx. Скорее всего кто-то из них.
xcache пишет кэш в /tmp. Есть смысл сделать для него tmpfs ?
В nginx 8 worker-ов. Есть смысл убавить до 4?
Kpd, а что пишет на диск? Загоните кеши в tmpfs, если памяти много. И SMART дисков скиньте.
В nginx 8 worker-ов. Есть смысл убавить до 4?
Зависит от количества ядер в системе.
И в вашем случае это ничего не поменяет.
Kpd, начните с изучения данных от iotop.
Kpd, начните с изучения данных от iotop.
Сейчас нагрузка примерно половина от пиковой.
Получается, что пишет только nginx логи (статика в лог не пишется).
И читает больше всех nginx
Может быть так, что nginx очень активно читает?
---------- Добавлено 30.04.2016 в 11:31 ----------
Вообще я заметил, что диски больше тормозят на чтении.
Например, создание бэкапов не вызывает заметных тормозов.
Но перекачка бэкапов через NFS уже заметна (la подскакивает с 3 до 10-12).
Может быть так, что nginx очень активно читает?
Может. Почему бы ему не читать, если это его основная функция ?
Да всего у вас понемножку и сосредоточиться не на чем.
По-моему, nginx многовато пишет. Вот от лишней записи имеет смысл избавляться.
Используются ли буферы ответов, то есть создаются ли файлы в /var/spool/nginx/cache/ ? Агрессивное кеширование в файлы (как у сеонизаторов модно) ?
А Вы уверены, что
Actual DISK READ: 913.92 K/s | Actual DISK WRITE: 375.29 K/s
это половина от пиковой нагрузки? Цифры то какие-то совсем крошечные.
Вы бы остановили всё и проверили скорость чтения с диска при нулевой активности. Может диски давно умерли.
Вы бы остановили всё и проверили скорость чтения с диска при нулевой активности. Может диски давно умерли.
production, нельзя останавливать
По-моему, nginx многовато пишет. Вот от лишней записи имеет смысл избавляться.
Опытным путем установил, что nginx пишут в access_log. Отключил все access_log и запись упала почти до 0.
Но глобально это ничего не изменило.
Используются ли буферы ответов, то есть создаются ли файлы в /var/spool/nginx/cache/
Есть кэширование страниц целиком, но в /tmpfs . Отключение его опять же не изменило нагрузку на диск (скорее стало хуже от самого факта отключения кэширования, оно сокращает примерно на 10% запросы к бэкаэнду).
Также попробовал уменьшить количество workier-ов в nginx. Не помогло.
Все вышеописанное делал по отдельности с перезапуском nginx.
---------- Добавлено 02.05.2016 в 11:22 ----------
Сегодня recync опять запустился. Сейчас пишет со скоростью 40Mb/s и пока проблем нет. Но и нагрузки на сервер нет (чуть больше половины пиковой).
Т.е. моя конструкция в cron не сработала
Как его заставить запускаться всего 1 раз в какой-нибудь понедельник месяца?
---------- Добавлено 02.05.2016 в 11:27 ----------
это половина от пиковой нагрузки? Цифры то какие-то совсем крошечные.
Да, абсолютные цифры крошечные.
Может быть проблема с какими-то лимитами на открытые файлы и т.п.?
---------- Добавлено 02.05.2016 в 11:30 ----------
В php-коде довольно много вызовов file_exists()- и getimagefilesize() (для локальных файлов)
Могут они так сильно дергать?
И есть 2 папки с 30к подпапок в каждой (и в каждой подпапке картинки). Может быть в этом корень зла?
---------- Добавлено 02.05.2016 в 11:40 ----------
Вот так сейчас выглядит iotop
---------- Добавлено 02.05.2016 в 11:58 ----------
Нет, я не прав. Отключение access_log дало результат. la постепенно снижается и тормозов нет. Но пока не знаю, что будет вечером под пиковой нагрузкой.