forum.lissyara.su

Добавлено: **2010-04-19 13:28:07**

имею вот такой конфиг:

srv1# grep -v ^# /usr/local/etc/my.cnf | grep -v ^\$
[client]
port            = 3306
socket          = /tmp/mysql.sock
default-character-set   = cp1251
[mysqld]
default-character-set   = cp1251
character-set-server    = cp1251
collation-server        = cp1251_general_ci
init-connect            = "SET NAMES cp1251"
long_query_time         = 20
skip-external-locking
old_passwords
bind-address           = 127.0.0.1
skip-bdb
innodb_file_per_table=1
max_connections         = 2000
connect_timeout         = 10
interactive_timeout     = 15
wait_timeout            = 15
net_read_timeout        = 30
net_write_timeout       = 30
max_connect_errors      = 10
max_tmp_tables          = 64
max_user_connection     = 32
port            = 3306
socket          = /tmp/mysql.sock
skip-locking
key_buffer = 512M
max_allowed_packet = 4M
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 16
query_cache_size= 32M
thread_concurrency = 6
server-id       = 1
[mysqldump]
quick
skip-extended-insert
max_allowed_packet = 16M
[mysql]
no-auto-rehash
default-character-set   = cp1251
[isamchk]
key_buffer = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M
[myisamchk]
key_buffer = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M
[mysqlhotcopy]
interactive-timeout
srv1#

в итоге сервер рамы юзает 155-160 мегов, резервирует 600.
но больше 160 чтоб использовал - такого не бывает.
немогу понять где я яего запилил, что не хочет раму кушать...

Добавлено: **2010-04-20 9:49:46**

_http://www.mysqlperformanceblog.com/2006/05/17 ... ory-usage/

Код: Выделить всё

key_buffer_size + (read_buffer_size + sort_buffer_size) * max_connections = K bytes of memory

Добавлено: **2010-04-21 16:05:14**

Ну что? решилось как-то?

Добавлено: **2010-04-21 16:13:24**

не ковырял даже...
пеернёс директорию для временных файлов в /tmp - там tmpfs - стал прилично меньше тупить и перестало совсем пилить диск (раньше на /var/tmp смотрело).
но глобально пока не занимался

Добавлено: **2010-04-21 17:07:34**

ааа, ты все еще не на innodb?

Вообще кол-во выделенной памяти - это то

innodb_pool + key_buffer_size + (read_buffer_size + sort_buffer_size) * max_connections

А кол-во используемой - занятый_innodb_pool + заняный_key_buffer_size + (read_buffer_size + sort_buffer_size) * текущие коннекты.

Добавлено: **2010-04-21 18:00:56**

я чё обкумаренный чтоли - и так медлено работает, а с этим кривым поделием будет вообще финиш

Добавлено: **2010-04-21 18:16:15**

>версия 5.5 MySQL будет по умолчанию использовать созданный в Oracle движок хранения данных InnoDB

Добавлено: **2010-04-21 18:41:39**

да пофигу
до 5.5 ещё как до луны пешком

Добавлено: **2010-04-21 20:13:13**

lissyara писал(а):да пофигу
до 5.5 ещё как до луны пешком

Отлично работает на продакшене 5.5. А про иннодб я уже говорил - ты просто не умеешь их готовить.

Добавлено: **2010-04-21 20:22:47**

а ну да... не умею...
а чем больше сталкиваюсь тем больше понимаю кривизну.
последний мелкий глюк - квота у юзера на хостинге кончилась - стоила мне 3 часов моего времени с 12 до 3 ночи - задампить все базы и зарестоить их обратно.
на MyISAM это мне стоило бы 10-15 секунд на набор

Код: Выделить всё

repair table...

Добавлено: **2010-04-21 20:55:21**

myisam это не БД, тебя кто-то в детстве абманул ;]

Добавлено: **2010-04-21 21:33:26**

меня целиком и полностью устраивает.
огребать новых глюков - не хочется

Добавлено: **2010-04-21 21:39:49**

постарел, заматерел

Добавлено: **2010-04-21 22:09:15**

нет. просто выводы из собственного опыта.
на InnoDB проблем было больше, решались они тяжелей и дольше.
последняя проблема что писывал - уж извнини но на MyISAM докатиться до состояния когда придётся дампить/ресторить все базы - это нонсенс...
(мера, правда, вынужденная - разбирать какая таблица в чём и дёргать тока InnoDB - было бы дольше)

Добавлено: **2010-04-22 12:46:59**

lissyara писал(а):нет. просто выводы из собственного опыта.
на InnoDB проблем было больше, решались они тяжелей и дольше.
последняя проблема что писывал - уж извнини но на MyISAM докатиться до состояния когда придётся дампить/ресторить все базы - это нонсенс...
(мера, правда, вынужденная - разбирать какая таблица в чём и дёргать тока InnoDB - было бы дольше)

Во первых InnoDB надо юзать с

Код: Выделить всё

innodb_file_per_table = 1

и не хранить, таким образом, все яйца в одной корзине и все таблицы в одном большущем файле ibdata.
Бакапить и ресторить всегда можно всего одну таблицу, не обязательно всю/все БД разом, это вам не Sybase с его бинарными дампами.
Кроме того, думать надо, перед тем как создавать таблицы в MyISAM или в InnoDB.
Если всяких foreign key и транзакций не надо то вполне себе myisam подходит.
А если надо транзакции... тут от InnoDB почти не отвертеться.
У нас большущие таблицы с кучей сырых данных в MyISAM, а вот то что поменьше и всякие справочники в InnoDB.
Мало кто говорит, но я уже с этим сталкивался, что innodb тож может побиться, или может слететь sequence версии бд таблицы... в общем у каждого engine свои сюрпризы

Добавлено: **2010-04-22 13:46:37**

Код: Выделить всё

innodb_file_per_table = 1

юзаю... но на том сервере не с рождения

)

Добавлено: **2010-04-22 17:40:34**

lissyara писал(а):нет. просто выводы из собственного опыта.
на InnoDB проблем было больше, решались они тяжелей и дольше.
последняя проблема что писывал - уж извнини но на MyISAM докатиться до состояния когда придётся дампить/ресторить все базы - это нонсенс...
(мера, правда, вынужденная - разбирать какая таблица в чём и дёргать тока InnoDB - было бы дольше)

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

Добавлено: **2010-04-22 19:52:56**

ADRE писал(а): оно бронировеннее хоть и не много другое... ссцылки там хоть как у нормального скуля пашут а не только в пхп майадмин ) эм я что путатю?, блокируются же записи в данной бд построчно, а на сколько помню в майсам колоночками, нет?

Именно так. +скорость давно на уровне isam.

Добавлено: **2010-04-23 0:14:36**

LMik писал(а):
ADRE писал(а): оно бронировеннее хоть и не много другое... ссцылки там хоть как у нормального скуля пашут а не только в пхп майадмин ) эм я что путатю?, блокируются же записи в данной бд построчно, а на сколько помню в майсам колоночками, нет?
Именно так. +скорость давно на уровне isam.

ага.
а теперь эмулируем падение сервера БД и удаляем... ну например ibdata1
использовались innodb_file_per_table = 1
ваши действия и бубны по подцеплянию всех пяти сотен баз в рабочем виде обратно?
==========
в myisam, я просто разложу то что уцелело обратно по папочкам.
минуты две это заёмёт.
вы же с вашим иннодб будете ебаться прилично дольше - ибо будете получать ругань на то что нумер таблеспейса станный, и рекомендацию убрать файл, создать нужную таблицу, дропнуть её, подсунуть нужный файл

)
уж не помню точный набор плясок с бубном, но нифига не впечатлило

)

Добавлено: **2010-04-23 13:33:26**

lissyara писал(а):
LMik писал(а):
ADRE писал(а): оно бронировеннее хоть и не много другое... ссцылки там хоть как у нормального скуля пашут а не только в пхп майадмин ) эм я что путатю?, блокируются же записи в данной бд построчно, а на сколько помню в майсам колоночками, нет?
Именно так. +скорость давно на уровне isam.
ага.
а теперь эмулируем падение сервера БД и удаляем... ну например ibdata1
использовались innodb_file_per_table = 1
ваши действия и бубны по подцеплянию всех пяти сотен баз в рабочем виде обратно?
==========
в myisam, я просто разложу то что уцелело обратно по папочкам.
минуты две это заёмёт.
вы же с вашим иннодб будете ебаться прилично дольше - ибо будете получать ругань на то что нумер таблеспейса станный, и рекомендацию убрать файл, создать нужную таблицу, дропнуть её, подсунуть нужный файл )
уж не помню точный набор плясок с бубном, но нифига не впечатлило )

а зачем тогда бэкап?

Добавлено: **2010-04-23 13:43:22**

действительно
зачем бэкап с прошлой ночи, когда уже нынешняя?

Добавлено: **2010-04-24 9:23:15**

какой результат то?
===
в другой теми мертись у кого доразвитая база у кого нет

Добавлено: **2010-04-24 9:40:12**

ну, сказать нечего по сабжу, вот и начали

Добавлено: **2010-04-24 9:46:46**

Как нечего? Все сказал же. У тебя макс конектов 2000 в конфиге, поэтому он выделяет памяти 600 метров под них. Посчитай. Когда все конекты будут подключены будет использована вся выделенная память.

LMik писал(а):ааа, ты все еще не на innodb?

Вообще кол-во выделенной памяти - это то

innodb_pool + key_buffer_size + (read_buffer_size + sort_buffer_size) * max_connections

А кол-во используемой - занятый_innodb_pool + заняный_key_buffer_size + (read_buffer_size + sort_buffer_size) * текущие коннекты.

Добавлено: **2010-04-24 9:49:50**

Хотя странно что 600 скушал, должен был много больше... Видимо какие то новые механизмы выделения стали работать. А посчитай размер индексов на всех базах, мож они как раз 160?

forum.lissyara.su

[MySQL] странности с использованием памяти

[MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти

Re: [MySQL] странности с использованием памяти