14.12.2012 14:10
Вроде все правильно, в любую папку, посмотри, он там еще требует калькулятора, кажется, я не знаю, есть он в штатной поставке или нет.
24.12.2012 05:33
Решил продолжить процесс оптимизации с помощь скрипта:



Скрипт положил по следующему пути /usr/opt/tuning-primer.sh! Выполнил команды
Цитата:
chmod +x /usr/opt/tuning-primer.sh
/usr/opt/tuning-primer.sh
Как и предположил Olegon калькулятора действительно не оказалось

Цитата:
which: no bc in (/usr/local/sbin:/usr/local/xorg/xinput_calibrator/bin:/usr/local/xorg/icewm/bin:/usr/local/xorg/xorg-deps/bin:/usr/local/xorg/xorg-main/bin:/usr/bin:/bin:/usr/sbin:/sbin:/root/bin)
Error: Command line calculator 'bc' not found!
Скачал bc-1.06! Пытаюсь его установить положил дистрибутив в папку по тому же пути /usr/opt/! Выполняю команды:

Цитата:
gunzip bc-1.06.tar.gz
tar xvf bc-1.06.tar
cd bc-1.06
./configure
После выполнения команды ./configure получил
Цитата:
loading cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... no
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... missing
checking for gcc... no
checking for cc... no
configure: error: no acceptable cc found in $PATH
Подскажите что не так и может существует какой другой способ установки данного калькулятора!

P.S И хотелось бы узнать, что является результатом выполнения скрипта tuning-primer.sh!
24.12.2012 07:26
про калькулятор - собери его еще где-нибудь, где такая же платформа...
сто касается скрипта - вот пример вывода:
скрытое
24.12.2012 11:12
rpm bc из дистрибутива redhat 9.0
https://storage.olegon.ru/supermag/u...12.i386.rpm.7z

Установка: rpm -ivh --nodeps bc-1.06-12.i386.rpm
25.12.2012 09:07
Получил результат выполнения скрипта ! Как сделать анализ полученных данных, и какие если нужно поправить параметры и где?
25.12.2012 12:30
"Сделать анализ полученных данных" - это для начала минимально знать технический английский. Там все написано, читайте.

Специалистом не являюсь, все "рекомендации" следуют из вывода скрипта.

Uptime = 0 days 0 hrs 0 min 31 sec
Warning: Server has not been running for at least 48hrs.
It may not be safe to use these recommendations


Нужно поработать хотя бы несколько часов под нагрузкой, и с теми операциями где тормозит.

SLOW QUERIES
The slow query log is NOT enabled.


Если интересны долго выполняемые запросы, в my.cnf
log_slow_queries=query-slow.log

INNODB STATUS
Current InnoDB index space = 86 M
Current InnoDB data space = 72 M
Current InnoDB buffer pool free = 94 %
Current innodb_buffer_pool_size = 640 M

MEMORY USAGE
Max Memory Ever Allocated : 743 M
Configured Max Per-thread Buffers : 468 M
Configured Max Global Buffers : 737 M
Configured Max Memory Limit : 1.17 G
Physical Memory : 1.96 G


C таким размером БД, она вся в кэше должна лежать и тормоза со стороны БД маловероятны, скорее приложение косячит.

QUERY CACHE
Query cache is supported but not enabled


Можно добавить в конфиг
query_cache_size = 16M
query_cache_limit = 2M

JOINS
Current join_buffer_size = 132.00 K
You have had 5 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.


Можно добавить в конфиг
log-queries-not-using-indexes
и смотреть запросы, не использующие индексы.
Если проблема в них (а переписать их нельзя), можно попробовать увеличить join_buffer_size, до 4M например

TABLE CACHE
Current table_cache value = 64 tables
You have a total of 454 tables
You have 64 open tables.
Current table_cache hit rate is 3%
, while 100% of your table cache is in use
You should probably increase your table_cache


Можно увеличить
table_cache = 512

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Of 201 temp tables, 9% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.


Можно увеличить
max_heap_table_size = 32M
16.06.2015 09:40
Помимо скрипта в 17 сообщении могу предложить еще один.
Код:
wget http://mysqltuner.pl/ -O mysqltuner.pl
chmod +x mysqltuner.pl
./mysqltuner.pl
на всякий случай прикладываю и сюда скрипт...
Вложения
Тип файла: 7z mysqltuner.7z (12.4 Кб, 124 просмотров)
26.10.2023 09:33



Я посмотрел два больших информативных вебинара про оптимизацию запросов в MySQL. Понятно, что в формате заметки невозможно раскрыть тему, поэтому я сделаю выжимку основных этапов и инструментов, которые используются. Кому нужна будет эта тема, сможет раскрутить её на основе этих вводных.

1️⃣ Включаем логирование запросов, всех или только медленных в зависимости от задач. В общем случае это делается примерно так:
log_error = /var/log/mysql/error.log
slow_query_log
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2.0
Для детального разбора нужны будут и более тонкие настройки.

2️⃣ Организуется, если нет, хотя бы базовый мониторинг MySQL, чтобы можно было как-то оценить результат и состояние сервера. Можно взять Zabbix, Percona Monitoring and Management, LPAR2RRD или что-то ещё.

3️⃣ Начинаем анализировать slow_query_log с помощью pt-query-digest из состава Percona Toolkit. Она выведет статистику по всем запросам, из которых один или несколько будут занимать большую часть времени работы СУБД. Возможно это будет вообще один единственный запрос, из-за которого тормозит весь сервер. Выбираем запросы и работаем дальше с ними. Уже здесь можно увидеть запрос от какого-то ненужного модуля, или какой-то забытой системы по собору статистики и т.д.

4️⃣ Если есть возможность, показываем запрос разработчикам или кому-то ещё, чтобы выполнили оптимизацию схемы БД: поработали с типами данных, индексами, внешними ключами, нормализацией и т.д. Если такой возможности нет, работаем с запросом дальше сами.

5️⃣ Смотрим план выполнения проблемного запроса, добавляя к нему в начало EXPLAIN и EXPLAIN ANALYZE. Можно воспользоваться визуализацией плана в MySQL Workbench. Если нет специальных знаний по анализу запросов, то кроме добавления индекса в какое-то место вряд ли что-то получится сделать. Если знания есть, то скорее всего и этот материал вам не нужен. Понимая, как работают индексы, и глядя на медленные места запроса, где нет индекса, можно попробовать добавить туда индекс и оценить результат. Отдельно отмечу, что если у вас в запросе есть где-то полное сканирование большой таблицы, то это плохо. Этого нужно стараться избегать в том числе с помощью индексов.

6️⃣ После того, как закончите с запросами, проанализируйте в целом индексы в базе с помощью pt-duplicate-key-checker. Она покажет дубликаты индексов и внешних ключей. Если база большая и имеет много составных индексов, то вероятность появления дубликатов индексов немалая. А лишние индексы увеличивают количество записей на диск и снижают в целом производительность СУБД.

7️⃣ Оцените результат своей работы в мониторинге. Соберите ещё раз лог медленных запросов и оцените изменения, если они есть.

В целом, тема сложная и наскоком её не осилить, если нет базовой подготовки и понимания, как работает СУБД. Разработчики, по идее, должны разбираться лучше системных администраторов в этих вопросах, так как структуру базы данных и запросы к ней чаще всего делают именно они.

Теорию и практику в том виде, как я её представил в заметке, должен знать администратор сервера баз данных, чтобы предметно говорить по этой теме и передать проблему тому, в чьей зоне ответственности она находится. Если разработчики нагородили таких запросов, что сайт колом стоит, то им и решать эту задачу. Но если вы им не покажете факты в виде медленных запросов, то они будут говорить, что надо увеличить производительность сервера, потому что для них это проще всего.

Я лично не раз с этим сталкивался. Где-то даже команду поменяли, потому что они не могли обеспечить нормальную производительность сайта. Другие пришли и всё сделали быстро, потому что банально разбирались, как это делается. А если разработчик не может, то ничего не поделать. И все будут думать, что это сервер тормозит, если вы не докажете обратное.
Часовой пояс GMT +3, время: 02:00.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.