- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Есть сервачок, двухядерный пень и 2 гига ОЗУ. Основную нагрузку на сервер создает большая база данных В какой-то момент индексы перестали умещаться в key_buffer и la резко вырос с 1 до 2. На времени загрузки страниц это пока не сказывается, но в пиках нагрузки la доходит до 3 и mysql-сервер на несколько секунд падает. Ранее возникали похожие проблемы, решалось настройкой my.cnf. Сейчас увеличил key_buffer до 1 гига, а ничего не изменилось. Не могу понять, что мне показывает top. key_buffer 1 гиг, значит mysql должен сразу откусить себе 1 гиг? Что означает "1063M Inact"?
106 processes: 1 running, 105 sleeping
CPU states: 44.3% user, 0.0% nice, 24.8% system, 0.8% interrupt, 30.2% idle
Mem: 518M Active, 1063M Inact, 280M Wired, 99M Cache, 112M Buf, 36M Free
Swap: 2048M Total, 8032K Used, 2040M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
63085 mysql 13 20 0 445M 219M kserel 0 79:08 63.28% mysqld
68362 apache 1 20 0 55924K 26556K lockf 1 0:18 2.49% httpd
68396 apache 1 20 0 54784K 25468K lockf 1 0:13 2.15% httpd
68827 apache 1 20 0 54656K 20908K lockf 1 0:04 1.95% httpd
68138 apache 1 20 0 54792K 25372K lockf 1 0:18 1.32% httpd
68781 apache 1 20 0 54796K 21356K lockf 1 0:06 1.27% httpd
68471 apache 1 20 0 54860K 24488K lockf 1 0:19 1.03% httpd
69043 apache 1 4 0 54816K 19012K kqread 1 0:01 0.97% httpd
68762 apache 1 20 0 54844K 24472K lockf 1 0:07 0.93% httpd
68763 apache 1 20 0 55104K 22184K lockf 1 0:06 0.93% httpd
15324 www 1 4 0 12480K 11872K kqread 1 102:59 0.00% nginx
15323 www 1 4 0 3756K 3148K kqread 1 100:13 0.00% nginx
15326 www 1 4 0 3132K 2512K kqread 1 99:37 0.00% nginx
15325 www 1 4 0 42112K 41540K kqread 1 99:23 0.00% nginx
19800 root 1 96 0 26336K 14548K select 0 63:46 0.00% perl
96673 bind 1 96 0 6444K 4224K select 1 61:46 0.00% named
мож пора уже памяти добавить на сервер, а не насиловать своп?
мож пора уже памяти добавить на сервер, а не насиловать своп?
Swap практически не испльзуется. Добавить памяти не проблема, но не уверен что это поможет.
ой. проглючил ;)
сам mysql не будет считывать индекс в память пока они не понадобятся, но может. чтобы полностью загрузить индекс попробуйте LOAD INDEX INTO CACHE. http://dev.mysql.com/doc/refman/5.0/en/index-preloading.html
у вас же не обязательно запросы используют только лишь индексы. наверняка там полное сканирование присутствует и тут вылезает высокая доля времени в system - 24.8%
у вас же не обязательно запросы используют только лишь индексы. наверняка там полное сканирование присутствует и тут вылезает высокая доля времени в system - 24.8%
Как можно вычислить такие запросы? В логе slow-queries вижу только запросы, использующие большие индексы. Иногда mysql ругается ошибками "1030: Got error 12 from storage engine", т.е. памяти не хватает?
А, теперь понятно. В freebsd, этой протухшей унылой иконе российского хостинга, чтобы программа смогла потребить больше чем 512Мб нужно в загрузчике специальные параметры указать. у меня есть bsd, там в loader.conf такое :
kern.maxdsiz="1610612736"
kern.dfldsiz="1610612736"
и перегрузить
что касается медленных запросов, то они должны фиксироваться как медленные. откуда вы знаете, что они у вас используют только лишь индексы?
в общем, если раньше вы решали проблемы увеличением key_buffer, значит и после перезагрузки сможете и дальше таким нехитрым методом продолжать.
Жалко перезагружать, uptime почти год :) Но наверное придется. Нашёл /boot/loader.conf , файл пустой. Это нормально, или я нашёл не тот conf?
Ещё попробую обновить nginx, сейчас стоит 0.6, попробую 0.7, может статику будет шустрее раздавать. С 0.6 совместимость конфигов nginx осталась?
нормально. этот нелепый момент даже в документации описан http://dev.mysql.com/doc/refman/5.1/en/freebsd.html
Там еще с ресурсными лимитами могут быть проблемы. Посмотрите еще, перед тем как менять и перезагружать, какие лимиты памяти у вас сейчас стоят.
Из по рута выполнить: ulimit -a, посмотреть значение data seg size (там в килобайтах). Если меньше гигабайта, то проверить, установится ли в шелле лимит на гигабайт: ulimit -d 10485676 и снова посмотреть через ulimit -a . Если устновится, то в бутлоадере менять ничего не нужно. Достаточно будет установить лимиты через login.conf, либо перед запуском mysqld установить их через ulimit.
Из по рута выполнить: ulimit -a
ulimit: Command not found.
(Фря 6.2)