А!!! Спасите!!!! :D

Кто бы б вообще помог рассчитать параметры для my.cnf, чтобы максимум производительности при укладывании в наличную память при пиковой загрузке

Сейчас - такое:

1. [mysqld]
2. ft_min_word_len=2
3.  
4. back_log    = 5
5. datadir     = /usr/local/var
6. port        = 3306
7. socket      = /var/lib/mysql/mysql.sock
8. skip-locking
9. key_buffer = 64M
10. max_allowed_packet = 1M
11. max_connections = 100
12. table_cache = 64
13. sort_buffer_size = 512K
14. read_buffer_size = 512M
15. myisam_sort_buffer_size = 32M
16.  
17. net_buffer_length = 8K
18.  
19. thread_cache = 8
20. query_cache_size= 8M
21. delayed_queue_size = 10
22. join_buffer_size = 256K
23. max_binlog_cache_size = 128M
24. tmp_table_size = 32M
25.  
26. thread_concurrency = 4
27.  
28. server-id   = 1
29.  
30. tmpdir      = /home/tmp/
31.  
32. innodb_buffer_pool_size = 128M
33.  
34. default-character-set=utf8

Это все криворукость борзо... э... датабазописцев!

к сожалению, не имел дела с mysql

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

Или тут

SEA, 23.04.2004 18:53:59 :

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

Или тут

 

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

Пробовать надо, потому и качественные. Хотя по первой ссылке есть указание, что есть несколько файлов-примеров для различных баз:

When you have installed MySQL, the `support-files' directory will contain some different `my.cnf' example files, `my-huge.cnf', `my-large.cnf', `my-medium.cnf', and `my-small.cnf'. You can use these as a basis for optimizing your system.

 

Можеш попробовать их?

Ром, а как ты делаешь перенос данных из одной таблицы в другую? Я бы сделал это одним SQL-ем

1. SELECT *
2. INTO table2
3. FROM table1

А MySQL кажеться так не умеет. Надо или использовать SELECT * INTO OUTFILE, а потом LOAD DATA INFILE или же использовать INSERT INTO table1 VALUES (row1), (row2),...,(rowN) с увеличением параметра bulk_insert_buffer_size

Mishka, 24.04.2004 04:17:52 :

Пробовать надо, потому и качественные.

 

В том-то и дело, что при всей любви к итеративным методам, нифига у меня подобрать параметры не выходит Ставишь мало - всё тормозит. Ставишь много - вроде, всё ок, но на следующий день в пике загрузки всё валится. Ставишь среднее значение - и тормозит и валится Это грубо, на самом деле, там ещё, похоже, параметры друг на друга влияют. Кроме того, где-то там есть оптимум. При малых значениях всё начинает виснуть от того, что каждый из запросов долго обрабатывается, и они начинают накапливаться, при больших - от того, что всё уходит в своп.

>Хотя по первой ссылке есть указание, что есть несколько файлов-примеров для различных баз

Ну, это даже, кажется, ./confugure в конце выдаёт А уж в README и INSTALL расписано. Фишка в том, что эти файлы абсолютно не наглядны. Такое впечатление, что писались они от фонаря. Я уже молчу о том, что там нет конфигурайия между 64Мб и 512Мб памяти

С файлом medium всё дико тормозит (иногда до 10и более секунд ждать отклика), с файлом large - при дневной загрузке всё уходит в своп. Сейчас значения где-то посередине, но создание FULLTEXT-индекса систему вешает даже при простом добавлении записей (сразу до 500Мб в свопе)

Mishka, 24.04.2004 04:59:34 :

А MySQL кажеться так не умеет.

 

Он умеет (синтаксис по памяти, могу стормозить)

1. INSERT INTO table2 SELECT * FROM table1;

Только разницы с прямым добавление индекса к имеющейся таблицы никакой

Что не удивительно, учитывая, что на ~100 тыс строк уже добавление даже просто новой строки вещь жутко тормозная при наличии FULLTEXT индекса :-/

Однозначно, мало памяти у компа и это главная проблема.
Можно ли в MySQL выставлять память для разных вещей раздельно? Была бы хоть какая то возможность оптимизации.
А вообще, видится только одно действенное и надежное решение - добавить памяти, и серьезно добавить.

Balancer, 23.04.2004 10:45:40 :

sort_buffer_size = 512K
read_buffer_size = 512M

 

Отчасти глюк был тут. Надо не так, а

1. sort_buffer_size = 512K
2. read_buffer_size = 512K

Теперь при долгой работе скрипта по переносу записей в FULLTEXT-таблицы память не теряется. Но всё равно невероятно долго. И ещё - такие таблицы не поддаются OPTIMIZE Сразу сыплется куча ошибок, после чего спасает только REPAIR.

Значит, буду переносить долго и понемногу.

Я тут почитал немного доку. Похоже, что они сортировку слиянием делают (ага, как будто есть другие методы:) для очень больших файлов) - попробуй sort_buffer_size увеличить раза в два-четыре и посмотреть, что получиться.

[ComputerMage:],27.04.2004 16:43:53

Ромка, поставь ReiserFS, ты просто удивишся как все залетает.

 

Это пока совершенно малореально. Это мне придётся сервер забирать от провайдера (на всё это время, естественно, ни Авиабаза, ни Диптаун пахать не будут ). При чём и дома геморрой будет ещё тот. Это ж всё куда-то бэкапить надо перед переразбивкой винтов и т.п.

>А если пересоберешь майсикл и кернел под П4 архитектуру, то это даст еще прирост производительности.

Дык, у меня они итак компилёные. За ядро, правда, не ручаюсь, давно было, а MySQL, PHP, Apache - всё из сорцов.

>Я по этой причине переполз на Генту Линукс.

Как раз сегодня где-то видел, что у них там с UTF-8 траблы

Mishka, 27.04.2004 16:09:21 :

попробуй sort_buffer_size увеличить раза в два-четыре и посмотреть, что получиться.

 

Увеличил. Внешне изменений особых нет. Ещё уменьшил максимальную длину слова в FULLTEXT с дефолтовых ft_max_word_len=254 до ft_max_word_len=64.

После того, как на форуме ввёл ограничение, не позволяющее обращаться к нему при превышении загрузки CPU более, чем на 10%, стало полегче, вроде.

[ Script Execution time: 0,1278 ] [ 13 queries used ] [ GZIP включён [uncompressed!] ] [ Server Load: 170,4% ] - сервер работает за двоих.

Mishka, 27.04.2004 19:42:30 :

[ Script Execution time: 0,1278 ] [ 13 queries used ] [ GZIP включён [uncompressed!] ] [ Server Load: 170,4% ] - сервер работает за двоих.

 

Процессоров-то два

>[ GZIP включён [uncompressed!] ]

Кстати, судя по всему, у тебя HTTP/1.1 через прокси выключен

>>Кстати, судя по всему, у тебя HTTP/1.1 через прокси выключен

Ром, думаешь, в США килобайты считают ? Да там, поди, фильмы качают из Интернета .

Павел Кузьмин, 27.04.2004 20:09:00 :

Ром, думаешь, в США килобайты считают ? Да там, поди, фильмы качают из Интернета .

 

Килобайты - нет. А вот для времени загрузки на глаз разница заметна С gzip оно мгновенно, а без - небольшая задержка есть

>>Килобайты - нет. А вот для времени загрузки на глаз разница заметна С gzip оно мгновенно, а без - небольшая задержка есть

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

А вот, наконец, удалось впервые явно поймать "запрос-убийцу"

1. SELECT p.pid FROM ib_posts p LEFT JOIN ib_bodies s ON (s.pid=p.pid)WHERE   p.forum_id IN (3) AND p.queued <> 1  AND ( LOWER(s.post) LIKE '%тб-7%' )

Время выполнения было 979 секунд, на время которых форумы, естественно, не отвечали.

С трудом представляю, что тут можно придумать в плане оптимизации, кроме перевода всего на FULLTEXT-индексы. Есть мнения?

Вот его EXPLAIN:

1. +----+-------------+-------+--------+----------------------+----------+---------+-------------+-------+-------------+
2. | id | select_type | table | type   | possible_keys        | key      | key_len | ref         | rows  | Extra       |
3. +----+-------------+-------+--------+----------------------+----------+---------+-------------+-------+-------------+
4. |  1 | SIMPLE      | p     | range  | PRIMARY,forum_id,pid | forum_id |       2 | NULL        | 56287 | Using where |
5. |  1 | SIMPLE      | s     | eq_ref | pid_2,pid            | pid_2    |       4 | FORUM.p.pid |     1 | Using where |
6. +----+-------------+-------+--------+----------------------+----------+---------+-------------+-------+-------------+
7. 2 rows in set (0,53 sec)

Павел Кузьмин, 27.04.2004 19:09:00 :

>>Кстати, судя по всему, у тебя HTTP/1.1 через прокси выключен

Ром, думаешь, в США килобайты считают ? Да там, поди, фильмы качают из Интернета .

 

Сорри - это я с работы - у нас там прокся не мной конфигурится. А фильмы - на раз.

С FULLTEXT поосторожней - вот примерчик, как это работает.

13.6 Full-text Search Functions

...
For example, although the word “MySQL” is present in every row of the articles table, a search for the word produces no
results:

code text

1.         mysql> SELECT * FROM articles
2.         -> WHERE MATCH (title,body) AGAINST ('MySQL');
3.         Empty set (0.00 sec)

The search result is empty because the word “MySQL” is present in at least 50% of the rows. As such, it is effectively treated as a stopword. For large datasets, this is the most desirable behavior—a natural language query should not return every second row from a 1GB table. For small datasets, it may be less desirable.

 

А вот объяснение про то, почему INSERT так медленно работает:

As of MySQL 3.23.23, MySQL has support for full-text indexing and searching.
A full-text index in MySQL is an index of type FULLTEXT. FULLTEXT indexes
are used with MyISAM tables only and can be created from CHAR, VARCHAR, or
TEXT columns at CREATE TABLE time or added later with ALTER TABLE or CREATE
INDEX. For large datasets, it will be much faster to load your data into a table
that has no FULLTEXT index, then create the index with ALTER TABLE (or CREATE
INDEX). Loading data into a table that already has a FULLTEXT index could be
significantly slower.

 

Ну, с примером всё ок, у меня FULLTEXT-поиск на Поиск по форуму пашет (если опять таблица не отвалилась).

А вот что до вставки - в том-то и прикол, что создание индекса то ли подвешивает систему, то ли так тормозит. Вчера решился на следственный эксперимент - сделал копию базы сообщений форума и запустил создание индекса. Благо, теперь, вроде, утечки памяти прекратились (вот уже почти сутки полёт MySQL нормальный).

Так вот, оно уже 51 тыс. секунд идёт процесс этот:

51046 Repair by sorting REPAIR TABLE `ib_bodies3`

А вот вставки (в другую таблицу) уже третьи сутки продолжаются помаленьку, уже под 2/3 засунуто