- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Здравствуйте форумчане,
Нужна Ваша помощь в оптимизации MySQL базы.
Ситуация такова, что страницы с товарами (20 шт. на странице) генерируются по 2-3 сек (и более), при этом CPU толком не нагружается. Страницы без товаров генерируются за 0.1-0.3 сек. Статика (сами картинки и тд) отдаются очень быстро.
Хост взят в аренду, на хосте стоит FreeBSD 7.0, Apache, php в режиме mod_php, nginx, APC.
Данные:
MySQL 5.0.67
Размер: ~200 МБ
198 таблиц, из них 90% InnoDB
Таблицы проиндексированы надлежащим способом, используется движек Magento.
Вот что помечает красным "состояние MySQL":
Innodb_buffer_pool_reads 1,393
Handler_read_rnd 141 k
Handler_read_rnd_next 2,540 k
Created_tmp_disk_tables 215 k
Key_writes 32 k
Opened_tables 264
Данные за 7 дней.
Пробовал увеличивать в 2-4 раза:
table_cache
sort_buffer_size
join_buffer_size
query_cache_size
tmp_table_size
key_buffer_size
read_buffer_size
read_rnd_buffer_size
bulk_insert_buffer_size
myisam_sort_buffer_size
innodb_additional_mem_pool_size
innodb_buffer_pool_size
Улучшения не заметны. :-(
Сам конфиг (почищен от коментариев):
Кто, что может подсказать по этому поводу?
Заранее спасибо.
длинные запросы в лог, потом explain
статус бы еще посмотреть. А так или самостоятельно или запустить туда умного человека, который все сделает.
Ситуация такова, что страницы с товарами (20 шт. на странице) генерируются по 2-3 сек (и более), при этом CPU толком не нагружается. Страницы без товаров генерируются за 0.1-0.3 сек. Статика (сами картинки и тд) отдаются очень быстро.
Хост взят в аренду, на хосте стоит FreeBSD 7.0, Apache, php в режиме mod_php, nginx, APC.
VDS? Сколько записей в таблице? Есть ли в таблицах с запросом text или blob поля?
P.S. Попробуйте отсортировать в MYSQL-таблице данные так же, как они выводятся на страницу ;)
Если процессор не нагружен, то вполне возможно, что это не вина mysql.
Скрипт чего-то ждет. Возможно там идет какой-то обращение во внешний мир. Попробуйте запустить netstat во время работы скрипта - может что-то заметите.
Еще может быть полезным расставить в скрипте метки времени, чтобы найти медленную часть. Типа echo "<!-- ".date("r")."-->"
Если таки mysql, попробуйте во время выполнения скрипта дать несколько раз с mysql-консоли
show full processlist;
Вы своими глазами сможете увидеть долгоиграющие запросы, если таковые есть.
А почему Вы так уверены что дело именно в настройках mysql ?
Тормоза могут давать и другие причины
Скрипт чего-то ждет. Возможно там идет какой-то обращение во внешний мир.
На диск, скорее всего, идёт это длительное обращение "во внешний мир". VDS отдаёт 5-10% скорости чтения с диска, данные раскиданы по всему диску, а в запросе идёт join на таблицах с полем типа text (такой запрос приводит к автоматическому сохранению промежуточной таблицы на диск вне зависимости от её размера). В итоге и тормоза без загрузки проца.
VDS отдаёт 5-10% скорости чтения с диска
Я извиняюсь что влезаю, но видимо это одна из причин по которой говорят что VDS все же хуже чем самый простой, но реальный сервер? Уже неоднократо слышал подобное утверждение.
VDS ...
У нас не VDS.
Это сервер в аренду. Atlon 2100LE, 2Gb ОЗУ.
А почему Вы так уверены что дело именно в настройках mysql ?
Тормоза могут давать и другие причины
Та вот тормоза имеено на тех старницах где больше всего идут запросы в mysql ... я бы сказал точнее - чем больше товаров на странице - тем дольше мы грузимся ... причем при 500 товарах, генерация страницы уже 30 сек.
С учетом того, что Magento грамотно кеширует блоки сайта (меню, подвалы и прочие куски страницы), причем эти блоки хранятся в tmpfs папке (в ОЗУ вообщем) + стоит еще APC, единственный вариант на что грешить - помоему на мускул.
статус бы еще посмотреть. А так или самостоятельно или запустить туда умного человека, который все сделает.
А есть такие, которые не будут греть ценой как за настройку сервера с нуля? :-)
У меня подозрение что проблема связанна с этими цифрами:
Handler_read_rnd 141 k
Handler_read_rnd_next 2,540 k
и проблема скорей всего гдето рядом ...
Вообщем попробую поковырять, промаркировать скрипты и посчитать время и задержки ...
Спасибо за советы.
У нас не VDS.
Это сервер в аренду. Atlon 2100LE, 2Gb ОЗУ.
На другие вопросы можете ответить или хотя бы поглялеть в ту сторону? ;)
P.S. "Страницы без товаров генерируются за 0.1-0.3 сек." - это очень медленно ☝
Вы лучше приведите текст скрипта, вызывающий столь мощный загруз. Сдаётся мне, что всё дело в его логике.