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

Теги:авиабаза
 
1 2 3
+
-
edit
 

Balancer

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

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

code apache
  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
 

Zeus

Динамик

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

SEA

втянувшийся

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

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

Или тут
 
+
-
edit
 

Balancer

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

Или тут
 


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

Mishka

модератор
★★☆
Пробовать надо, потому и качественные. Хотя по первой ссылке есть указание, что есть несколько файлов-примеров для различных баз:
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.
 

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

Mishka

модератор
★★☆
Ром, а как ты делаешь перенос данных из одной таблицы в другую? Я бы сделал это одним SQL-ем
code text
  1. SELECT *
  2. INTO table2
  3. FROM table1
 
+
-
edit
 

Mishka

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

Balancer

администратор
★★★★☆
Mishka, 24.04.2004 04:17:52 :
Пробовать надо, потому и качественные.
 


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

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

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

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

 
+
-
edit
 

Balancer

администратор
★★★★☆
Mishka, 24.04.2004 04:59:34 :
А MySQL кажеться так не умеет.
 


Он умеет (синтаксис по памяти, могу стормозить)
code mysql
  1. INSERT INTO table2 SELECT * FROM table1;


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

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

SEA

втянувшийся

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

Balancer

администратор
★★★★☆
Balancer, 23.04.2004 10:45:40 :
sort_buffer_size = 512K
read_buffer_size = 512M
 


Отчасти глюк был тут. Надо не так, а
code apache
  1. sort_buffer_size = 512K
  2. read_buffer_size = 512K


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

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

Mishka

модератор
★★☆
Я тут почитал немного доку. Похоже, что они сортировку слиянием делают (ага, как будто есть другие методы:) для очень больших файлов) - попробуй sort_buffer_size увеличить раза в два-четыре и посмотреть, что получиться.
 
CA [ComputerMage] #27.04.2004 16:43
+
-
edit
 
Balancer, 16.04.2004 16:48:35 :
someuser, 16.04.2004 17:37:37 :
Скорость работы с файлами в общем-то зависит только о того, как эту работу организовать...
 


Всё равно поиск файла в ОС слишком накладная операция, даже при использовании структур в духе БД, типа как в NTFS.

>Вы удивеитесь, но iXBT до сих пор на флатах висит.

Не удивлюсь, т.к. знаю это :D
Такие тормоза, глюки и малые возможности форума при таких малых объёмах баз - это только на plain/text'е изобразить можно :D

Как раз позавчера очень много там сидел в поисках инфы по фотику - я очень давно так не матерился :)
 


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

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

Balancer

администратор
★★★★☆
[ComputerMage:],27.04.2004 16:43:53
Ромка, поставь ReiserFS, ты просто удивишся как все залетает.
 


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

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

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

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

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

Balancer

администратор
★★★★☆
Mishka, 27.04.2004 16:09:21 :
попробуй sort_buffer_size увеличить раза в два-четыре и посмотреть, что получиться.
 


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

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

Mishka

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

Balancer

администратор
★★★★☆
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 через прокси выключен :)
 
RU Павел Кузьмин #27.04.2004 20:09
+
-
edit
 

Павел Кузьмин

координатор


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

Ром, думаешь, в США килобайты считают :) ? Да там, поди, фильмы качают из Интернета :P .
[font color="green"]Good Old Fashioned Lover Boy[/font]
 
+
-
edit
 

Balancer

администратор
★★★★☆
Павел Кузьмин, 27.04.2004 20:09:00 :
Ром, думаешь, в США килобайты считают :) ? Да там, поди, фильмы качают из Интернета :P .
 


Килобайты - нет. А вот для времени загрузки на глаз разница заметна :) С gzip оно мгновенно, а без - небольшая задержка есть :)
 
RU Павел Кузьмин #27.04.2004 20:15
+
-
edit
 

Павел Кузьмин

координатор


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

Ну тады, Михаил, не поленись заглянуть в настройки Осла, чтобы не томиться более ожиданием вывода вожделенных страниц на экран.
[font color="green"]Good Old Fashioned Lover Boy[/font]
 
+
-
edit
 

Balancer

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

code mysql
  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-индексы. Есть мнения?
 
+
-
edit
 

Balancer

администратор
★★★★☆
Вот его EXPLAIN:

code text
  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 в 21:32
+
-
edit
 

Mishka

модератор
★★☆
Павел Кузьмин, 27.04.2004 19:09:00 :
>>Кстати, судя по всему, у тебя HTTP/1.1 через прокси выключен

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


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

Mishka

модератор
★★☆
С 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.
 
 
+
-
edit
 

Balancer

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

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

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

51046 Repair by sorting REPAIR TABLE `ib_bodies3`

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

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru