Большая таблица mysql и быстродействие

iZk

Новичок
Большая таблица mysql и быстродействие

PHP:
mysql> desc metadata;
+-----------+----------------------+------+-----+---------+----------------+
| Field     | Type                 | Null | Key | Default | Extra          |
+-----------+----------------------+------+-----+---------+----------------+
| meta_id   | int(11) unsigned     | NO   | PRI | NULL    | auto_increment |
| path      | text                 | NO   |     |         |                |
| name      | varchar(255)         | NO   |     |         |                |
| size      | int(10) unsigned     | NO   |     | 0       |                |
+-----------+----------------------+------+-----+---------+----------------+
В настоящий момент кол-во строк в таблице около 2,5 миллионов. Размер с индексами ~450 мб. Ожидаю, что в течение года этот показатель увеличится в десять раз. И на этом остановится.

Индекс PRIMARY на meta_id

Запросы происходят следующие:
PHP:
SELECT * FROM metadata WHERE meta_id IN (1, 2, 3, .... здесь до 200 id)
Время выполнения запроса скачет от 0.05 сек и вплоть до 1.5

Вот моя конфигурация.

PHP:
my.cnf:
[mysqld]

skip-bdb
skip-innodb
skip-external-locking
skip-networking
concurrent_insert       = 0
key_buffer              = 512M
max_allowed_packet      = 8M
thread_stack            = 128K
thread_cache_size       = 64
max_connections         = 100
sort_buffer_size        = 128M
read_buffer_size        = 256M
join_buffer_size        = 128M
table_cache             = 8192
thread_concurrency      = 8
query_cache_limit       = 32M
query_cache_size        = 128M
tmp_table_size          = 256M
max_heap_table_size     = 256M
PHP:
debian:~# ps u 1836
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
mysql     1836  0.5 17.8 686156 368844 ?       Sl   Mar30  11:00 /usr/sbin/mysqld ...
Подозреваю, что именно в настройках my.cnf что-то не так

Система: Intel(R) Xeon(TM) CPU 3.00GHz, 2GB RAM, debian 2.6.18-6-amd64 ... x86_64, SATA RAID 5, mysql 5.0 из пакетов debian, под базу хочу выделить 50-60% озу
 

Gas

может по одной?
iZk
тип таблицы какой? запросы, которые выполняются по 1.5 после второго запуска уже идут по 0.0x sec ?
 

iZk

Новичок
Gas
Если речь идет о кеше, то это не совсем верно. Можно сформировать запрос ранее неизвестный системе и она его отработает моментально.

Дополнение:
UPDATE, INSERT, DELETE - в 5 утра. В рабочее время нету.
Всего в сутки проходит около 400 SELECT запросов. т.е. нагрузка небольшая. Параллельных задач нет.
 

Gas

может по одной?
Wicked
ага, провтыкал :)

Всего в сутки проходит около 400 SELECT запросов
если не планируется увеличение количества запросов на порядок, а то и на 2 - я бы забил :)

Если речь идет о кеше, то это не совсем верно.
думал (возможно так и есть) тормоза возникают когда индексов нет в key_buffer и данных в кеше oc. (повторный запрос с опцией SQL_NO_CACHE запускать)
 

iZk

Новичок
Народ спасибо за помощь! Тормоза были в дисковой системе.

Сейчас запросы стабильно выполняются со скоростью: ~0.004 сек

Однако еще один вопрос остается открытым: как заставить работать mysql "из озу"? Чтобы свести обращения к диску вообще на ноль.
 

nail

Новичок
Автор оригинала: iZk
Однако еще один вопрос остается открытым: как заставить работать mysql "из озу"? Чтобы свести обращения к диску вообще на ноль.
Насколько я знаю, myisam использует кеш операционной системы для IO операций. То есть вопрос сводится к тому, как заставить операционную систему полностью закешировать файлы базы данных.

У innodb есть свой кеш, там проще, можно указать в настройке достаточно большой буфер innodb и "echo 0 > /proc/sys/vm/swappiness".
 

440hz

php.ru
мож и не в тему, но я выкинул тормознутые запросы в memcache и поднял производительность в 100 раз.

было 1-2 сек на страницу. стало 0.02

ооочень доволен....
сейчас сайт держит 60000 хостов в сутки при генерации страницы от 0.1 до 0.02 даже не напрягаясь. хотим догнать до 100000.
 

Gas

может по одной?
Beavis
не memory
- MEMORY tables use a fixed-length row storage format.
- MEMORY tables cannot contain BLOB or TEXT columns.
440hz
тут же другой случай, нужен кеш не запросов, а произвольный доступ к любым записям из набора в 2.5M единиц да ещё с полями text+varchar(255). Загнать в memcache можно, но тратить несколько гиг под это дело при количестве запросов до 1000 в сутки жалко :) А если не жалко, чтоб не плодить сущности можно попробовать просто перевести в innodb и увеличить innodb_buffer_pool_size

iZk
а ну признавайся что ты тюнил :), на уровне системы/ос чё-то или просто load index сделал ?
 
Сверху