- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
а я попрошу my.cnf - в кеше кто-то сидит просто.
Хатя... БД должны быть поболее нагружены... В памяти, скорее всего, именно они и часть ФС что чаще всего используется на чтение.
Прикрепил my.cnf.
Ну по идеи да, но почему в нужный момент оно не очищает часть кеша, а свопит.. проблема именно в этом.
ok.Совсем по делу ничего сказать не могу, но давайте попробуем. PHP у вас не как fcgi случаем?
Перезапустите MySQL и если кеш не освободится - апач (nginx) у сервера. Так же предлагаю поставить htop - им удобнее наблюдать за сими процессами.
Это из разряда танцев с бубном, но покажет, кто именно использует кеш, т.к. при перезапуске сервисов помимо освобождения used RAM еще освободятся и кеш и буферы.
если уж вам так важно чтобы в своп не лезло - уменьшайте key_buffer_size
скорее всего в нем много страниц, которые используются реже чем файлы, вот ОС и решает их вытеснить.
ну и vm.swapiness зачем же увеличивать было. назло Линусу? оставьте 0.
Тормозит у вас явно из-за какого-то периодического процесса типа ротации логов или бекапа. Может быть, если его исключить или убавить ему прыти, то будет полегче.
В принципе можно сделать такой бекап, который не будет портить буферы ОС. Но вам дешевле будет памяти добавить.
Raistlin, стоит php cli. Тут на графике виден как раз перезапуск mysql + перезапуск httpd и nginx. Естественно резко уменьшилась память под приложения (мускул до этого весил 7ГБ в памяти, сейчас 6ГБ и потихоньку растет), но кеш системы все равно не сбрасывается.
htop стоит, ну сколько не смотрел - никогда ничего криминального не было. Единственное, как поставил eaccelerator, munin пишет apache ram usage 10-25ГБ, ну этого просто быть не может - совершенно не совпадает с показателями использования памяти, та и тогда в свопе было б очень много всего.
netwind, vm.swapiness поставил в 0. Уменьшать key_buffer_size наверное не стоит, т.к. там 5,5ГБ индексов. Каждую ночь сливаются базы данных + раз в неделю делается полный бекап, ротация логов нагружать не может (у большинства логов стоит симлинк на /dev/null). Но в своп уходит и без бекапов - по первому графику, начало уходить в своп в 7-8утра, а бекап баз длился с 1:30 до 1:57.
По поводу убавления прыти - стоит spri, который выставляет всем процессам nice и ionice. Памяти добавить нельзя - это максимум.
Уменьшать key_buffer_size наверное не стоит, т.к. там 5,5ГБ индексов
и где логика? размер индексов никак не характеризует частоту их использования.
перечитай еще раз мое сообщение.
вероятно, в этой конфигурации ОС считает индексы в памяти менее приоритетными чем остальное и вытесняет их в своп.
Уменьшить key_buffer_size придется, если хочется чтобы своп не использовался.
---------- Добавлено 22.01.2012 в 17:27 ----------
По поводу убавления прыти - стоит spri, который выставляет всем процессам nice и ionice.
зачем ВСЕМ ?
По задумке, nice и ionice нужно выставлять процессу бекапа и другим задачам, время выполнения которых не критично для нормальной работы сайта. До некоторой степени это даже помогает.
и где логика? размер индексов никак не характеризует частоту их использования.
перечитай еще раз мое сообщение.
вероятно, в этой конфигурации ОС считает индексы в памяти менее приоритетными чем остальное и вытесняет их в своп.
Уменьшить key_buffer_size придется, если хочется чтобы своп не использовался.
Тут сразу не понял. Ну а если уменьшить, не получится ли так, что индексы малонагруженных баз попадут в кеш, а индексы нагруженных баз - останутся вообще без кеша?
зачем ВСЕМ ?
По задумке, nice и ionice нужно выставлять процессу бекапа и другим задачам, время выполнения которых не критично для нормальной работы сайта. До некоторой степени это даже помогает.
Ну не для всех, но он делается и для httpd, nginx, mysql (так в статье вычитал, та и в начальных конфигах spri также - апач имеет высокий приоритет, мускул - средний). Для cp, rm, tar, gzip, rsync и ряда других nice 19 и ionice 7, для httpd и nginx - 2 и 1, для mysql - 7 и 4.
---------- Добавлено 22.01.2012 в 16:34 ----------
Сейчас вообще отключил своп, вроде памяти всем хватает. Вообще способ наверное варварский, но вроде все нормально. Сейчас и бекап идет, но работает как должно - когда остается свободной памяти меньше 200МБ, сгружает часть кеша и свободной становится около 500МБ.
Тут сразу не понял. Ну а если уменьшить, не получится ли так, что индексы малонагруженных баз попадут в кеш, а индексы нагруженных баз - останутся вообще без кеша?
не должно, если найти баланс.
Судя по графику CPU usage очень большая часть usr трансформировалась в nice. Может быть стоит приоритет mysql уравнять с остальными программами обслуживающими сайт. Ведь mysql тоже формирует странички сайта.
не должно, если найти баланс.
Ясно, ну как бекап закончится - тогда попробую поиграться с настройками, т.к. iowait сейчас итак большой, а рестарт мускула точно добьет.
Судя по графику CPU usage очень большая часть usr трансформировалась в nice. Может быть стоит приоритет mysql уравнять с остальными программами обслуживающими сайт. Ведь mysql тоже формирует странички сайта.
Поставил нгинкс, апач и мускул в высокоприоритетные приложения, график не меняется - юзер 20%, найс 180%. Правда в стандарте у spri кронзадание раз в 45минут (если не ошибаюсь), я поставил раз в 2 минуты - но не думаю, что это важно - т.к. он все равно просто чекает все процессы и почти всегда old и new priority равны. А вот когда бекапинг начинает делаться 45 минут слишком большой отрезок времени.
как поставил eaccelerator
И что вы хотите? Это его кеш. Видимо, вы апач не ребутаете, а релоадите... Иначе кеш должен был быть очищен, т.к. модуль выгружается. Правьте настройки и будет вам счастье.
И что вы хотите? Это его кеш. Видимо, вы апач не ребутаете, а релоадите... Иначе кеш должен был быть очищен, т.к. модуль выгружается. Правьте настройки и будет вам счастье.
Кеш eaccelerator идет на tmpfs /var/tmp и там же mysql-slow.log и выделено всего 6ГБ, из которых используется не более 30%. По идеи, эти данные занимать более 2ГБ в озу просто не могут.
По поводу рестарта апача, 16ГБ cached до рестарта и 14,5ГБ после, команда service httpd restart.