LINUX.ORG.RU
Форум — Admin  

Mysql - /tmp

 ,


0

1

Собственно вопрос - много кто пробовал держать директорию для временных таблиц на tmpfs? Как оно в плане засирания памяти и свопа? Объясняю зачем надо - в текущем состоянии (всё это дело сейчас на UFS) любые запросы в EXPLAIN которых видно «using filesort» дичайше тормозят сервер. У меня на предыдущей работе была именно tmpfs, но там не было дофигагиговых баз.

☆
← OTRS + LDAP TLS
PHP-CGI + nginx + Bad gateway error →

Сам не делал такого, но люди делали:

http://www.unix.ck.ua/content/tmpfs-failovaya-sistema-pamyati

http://www.mindflow.su/freebsd/mysql-tmpfs/

В плане засирания памяти выйдет замечательно - может все сожрать вместе со свапом.

По мне логичнее разработчиков напрягать в плане избавления от лишних join-ов или добавления индексов.

sergv ★
()
Ответ на: комментарий от sergv

Не все запросы без join одинаково полезны

mysql> EXPLAIN SELECT * FROM table AS r1 INNER JOIN( SELECT CEIL(RAND() * (SELECT MAX(ID) from table)) AS ID ) AS r2 WHERE r1.ID >= (r2.ID-10) AND r1.status='ok' AND r1.req_field != '' ORDER BY r1.ID ASC LIMIT 1;
+----+-------------+------------+--------+---------------+---------+---------+------+------+------------------------------+
| id | select_type | table      | type   | possible_keys | key     | key_len | ref  | rows | Extra                        |
+----+-------------+------------+--------+---------------+---------+---------+------+------+------------------------------+
|  1 | PRIMARY     | <derived2> | system | NULL          | NULL    | NULL    | NULL |    1 |                              |
|  1 | PRIMARY     | r1         | range  | PRIMARY       | PRIMARY | 4       | NULL |  227 | Using where                  |
|  2 | DERIVED     | NULL       | NULL   | NULL          | NULL    | NULL    | NULL | NULL | No tables used               |
|  3 | SUBQUERY    | NULL       | NULL   | NULL          | NULL    | NULL    | NULL | NULL | Select tables optimized away |
+----+-------------+------------+--------+---------------+---------+---------+------+------+------------------------------+
4 rows in set (0.00 sec)

mysql> EXPLAIN SELECT * FROM ta WHERE status='ok' AND req_field != '' ORDER BY RAND() LIMIT 1;+----+-------------+--------------+------+---------------+------+---------+------+------+----------------------------------------------+
| id | select_type | table        | type | possible_keys | key  | key_len | ref  | rows | Extra                                        |
+----+-------------+--------------+------+---------------+------+---------+------+------+----------------------------------------------+
|  1 | SIMPLE      | table | ALL  | NULL          | NULL | NULL    | NULL |  702 | Using where; Using temporary; Using filesort |
+----+-------------+--------------+------+---------------+------+---------+------+------+----------------------------------------------+
svr4 ☆
() автор топика
Ответ на: комментарий от ventilator

Для таблички с тыщей записей сойдёт. Пичаль начинается потом, когда быдлокодера увольняют «за ненадобностью», а табличка пухнет до >50000.

svr4 ☆
() автор топика
Ответ на: комментарий от ventilator

А почитать мануал и сделать sort_buffer_size больше не?

Плюсану, однако.

Если промежуточная табличка не в гектарах меряется - лечит.

sergv ★
()
Ответ на: Не все запросы без join одинаково полезны от svr4

Тоже дополню: tmp_table_size и max_heap_table_size.

по сабжу: Пока запросы не оптимизировали - /tmp(только для mysql) было в zram. Это сжатый tmpfs. Потом выключил за ненадобностью, когда всё допилили.

fjoe ★
()
Ответ на: комментарий от ventilator

Ага. В теории. А на деле - 146% быдлокодеров не умеют ни во что кроме мусыкуэля, и уметь не хотят. У нас есть единицы пользователей с базами на Postgres и Oracle, так вот почему-то они доставляют меньше всего проблем. Хотя базы у них большие и запросов много.

svr4 ☆
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← OTRS + LDAP TLS
Admin
PHP-CGI + nginx + Bad gateway error →