|
Задавайте вопросы, мы ответим
Вы не зашли.
Добрый день.
Имеем My SQL 5.1 на WinServer 2003 (32 разрядную).
Вопрос № 1: Периодически имеем ошибку Out of Memory Needed 16777224 bytes. Происходит вставка строк (почти каждую секунду, или несколько в одну секунду). Виртуальная память в этот момент 1,8Гб. Show status в этот момент выдает:
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 430788, signal count 420931
Mutex spin waits 0, rounds 6370882, OS waits 150341
RW-shared spins 518908, OS waits 252673; RW-excl spins 69082, OS waits 10082
------------------------
LATEST DETECTED DEADLOCK
------------------------
081020 11:59:16
*** (1) TRANSACTION:
TRANSACTION 0 975736142, ACTIVE 1 sec, OS thread id 2916 updating or deleting
mysql tables in use 1, locked 1
LOCK WAIT 4 lock struct(s), heap size 1024, 3 row lock(s), undo log entries 1
MySQL thread id 12112, query id 20641354 Betta.goe.esbyt.local 172.23.113.2 dim Updating
update f_um set f_um.`SUM`=If( NAME_CONST('x_sum',0) >= 0, NAME_CONST('x_sum',0), 0), f_um.`KEY_GLOB` = (extractvalue( NAME_CONST('x_pokazania',_utf8'<?xml version=\""1.0\"" encoding=\""UTF-8\""?><mas><row><col>35208</col><col>WWWWWW</col><col>0</col><col>0</col><col>0</col><col>0</col><col>2008-09-30</col><col>1007</col><col>1</col><col>0</col><col>0</col><col>0</col><col>+РTв+РT-+СTЗ+РT¦+РT- +СTГ+СTЗ+РT¦+СTВ+РT- +РT-+РT-+РT¦+РT++РT¦+РT-+РT-, +РT-+РT- +СTА+РT¦+РT-+РT¬+СTМ+РT-+СTЛ+РT¦ +вTДTЦ +РT++РT-+РT¦+РT-+РT-+РT-+СTА+РT- +РT-+РT¦ +СTА+РT-+РT-+РT¦+РT- +РT-+РT¬+РT¬+РT¬+РT¬+РT-+РT¦+РT-+РT-+РT-+РT-+СTГ 932120 +РT-+РT¦ +СTА+РT-+РT-+РT¦+РT- 0</col><col>0</col><col>0</col><col>0</col><col>0</col><col>0</col><col>0</col></row></mas>'),'//row[$x_iii]/col[14]')*1), f_um.`dpg`=extractvalue( NAME_CONST('x_pokazania',_utf8'<?xml version=\""1.0\"" encoding=\""UTF-8\""?><mas><row><col>35208</col><col>WWWWWW</col><col>0</col><col>0</col><col>0</col><col>0</col><col>2008-09-30</col><col>1007</col><col>1</col><col>0</col><col>0</col><col>0</col><col>+РTв+РT-+СTЗ+РT¦+РT- +СTГ+СTЗ+РT¦+СTВ+РT- +РT-+РT-+РT¦+РT++РT¦+РT-+РT-, +РT-+РT- +СTА+РT¦+РT-+РT¬+СTМ+РT-+СTЛ+РT¦ +вTДTЦ +РT++РT-+РT¦+РT-+РT-+РT-+СTА+РT- +РT-+РT¦ +СTА+РT-+РT-+РT¦+РT- +РT-+РT¬+РT¬+РT¬+РT¬+РT-+РT¦+РT-+РT-+РT-+РT-+СTГ 932120 +РT-+РT¦ +СTА+РT-+РT-+РT¦+РT- 0</col><col>0</col><col>0</col><col>0</col><col>0</col><col>0</col><col>0</col></row></mas>'),'//row[$x_iii]/col[7]'), f_um.`dpo`=if( (trim(extractvalue( NAME_CONST('x_pokazania',_utf8'<?xml version=\""1.0\"" encoding=\""UTF-8\""?><mas><row><col>35208</col><col>WWWWWW</col><col>0</col><col>0</col><col>0</col><col>0</col><col>2008-09-30</col><col>1007</col><col>1</col><col>0</col><col>0</col><col>0</col><col>+РTв+РT-+СTЗ+РT¦+РT- +СTГ+СTЗ+РT¦+СTВ+РT- +РT-+РT-+РT¦+РT++РT¦+РT-+РT-, +РT-+РT- +СTА+РT¦+РT-+РT¬+СTМ+РT-+СTЛ+РT¦ +вTДTЦ +РT++РT-+РT¦+РT-+РT-+РT-+СTА+РT- +РT-+РT¦ +СTА+РT-+РT-+РT¦+РT- +РT-+РT¬+РT¬+РT¬+РT¬+РT-+РT¦+РT-+РT-+РT-+РT-+СTГ 932120 +РT-+РT¦ +СTА+РT-+РT-+РT¦+РT- 0</col><col>0</col><col>0</col><col>0</col><col>0</col><col>0</col><col>0</col></row></mas>'),'//row[$x_iii]/col[17]'))*1)>0, extractvalue( NAME_CONST('x_pokazania',_utf8'<?xml version=\""1.0\"" encoding=\""UTF-8\""?><mas><row><col>35208</col><col>WWWWWW</col><col>0</col><col>0</col><col>0</col><col>0</col><col>2008-09-30</col><col>1007</col><col>1</col><col>0</col><col>0</col><col>0</col><col>+РTв+РT-+СTЗ+РT¦+РT- +СTГ+СTЗ+РT¦+СTВ+РT- +РT-+РT-+РT¦+РT++РT¦+РT-+РT-, +РT-+РT- +СTА+РT¦+РT-+РT¬+СTМ+РT-+СTЛ+РT¦ +вTДTЦ +РT++РT-+РT¦+РT-+РT-+РT-+СTА+РT- +РT-+РT¦ +СTА+РT-+РT-+РT¦+РT- +РT-+РT¬+РT¬+РT¬+РT¬+РT-+РT¦+РT-+РT-+РT-+РT-+СTГ 932120 +РT-+РT¦ +СTА+РT-+РT-+РT¦+РT- 0</col><col>0</col><col>0</col><col>0</col><col>0</col><col>0</col><col>0</col></row></mas>'),'//row[$x_iii]/col[17]'), extractvalue( NAME_CONST('x_pokazania',_utf8'<?xml version=\""1.0\"" encoding=\""UTF-8\""?><mas><row><col>35208</col><col>WWWWWW</col><col>0</col><col>0</col><col>0</col><col>0</col><col>2008-09-30</col><col>1007</col><col>1</col><col>0</col><col>0</col><col>0</col><col>+РTв+РT-+СTЗ+РT¦+РT- +СTГ+СTЗ+РT¦+СTВ+РT- +РT-+РT-+РT¦+РT++РT¦+РT-+РT-, +РT-+РT- +СTА+РT¦+РT-+РT¬+СTМ+РT-+СTЛ+РT¦ +вTДTЦ +РT++РT-+РT¦+РT-+РT-+РT-+СTА+РT- +РT-+РT¦ +СTА+РT-+РT-+РT¦+РT- +РT-+РT¬+РT¬+РT¬+РT¬+РT-+РT¦+РT-+РT-+РT-+РT-+СTГ 932120 +РT-+РT¦ +СTА+РT-+РT-+РT¦+РT- 0</col><col>0</col><col>0</col><col>0</col><col>0</col><col>0</col><col>0</col></row></mas>'),'//row[$x_ii
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 13 page no 56397 n bits 216 index `DPO` of table `subul`.`f_um` trx id 0 975736142 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 8; hex 8000124374b43397; asc TА CtT+3TЧ;; 1: len 4; hex 8025cbcb; asc TА%+Л+Л;;
*** (2) TRANSACTION:
TRANSACTION 0 975734360, ACTIVE 9 sec, OS thread id 5488 fetching rows, thread declared inside InnoDB 89
mysql tables in use 1, locked 1
2360 lock struct(s), heap size 159040, 198819 row lock(s), undo log entries 671
MySQL thread id 10811, query id 20596235 dimongo.goe.esbyt.local 172.23.113.11 root updating
DELETE FROM f_um WHERE f_um.RECEIPT = 1007 AND f_um.DPO > '2008-09-20' and nach=0
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 13 page no 56397 n bits 216 index `DPO` of table `subul`.`f_um` trx id 0 975734360 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 8; hex 8000124374b43397; asc TА CtT+3TЧ;; 1: len 4; hex 8025cbcb; asc TА%+Л+Л;;
.................................
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 1521, seg size 1523,
110818 inserts, 110815 merged recs, 64937 merges
Hash table size 3112859, used cells 753063, node heap has 847 buffer(s)
254000.00 hash searches/s, 625000.00 non-hash searches/s
---
LOG
---
Log sequence number 198 1250007700
Log flushed up to 198 1250002897
Last checkpoint at 198 1249951335
0 pending log writes, 0 pending chkp writes
421241 log i/o's done, 13000.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 830961750; in additional pool allocated 5242880
Dictionary memory allocated 882976
Buffer pool size 48000
Free buffers 4
Database pages 47149
Modified db pages 84
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages read 5343055, created 1419920, written 1811817
1000.00 reads/s, 24000.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000
Проблема ли это достижения максималки выделения памяти на процесс в винде? или в другом причина?
Вопрос№2: Периодически при инсерте этот процесс зависает на 40 секунд, обычно до секунды. При чем это происходит в последние 2 секунды, например в 09:52:59 или 19:07:58, что это?
Неактивен
Не уверен, но, кажется, Windows умеет выделять до трех гигабайт на процесс на 32битной
системе (если я не прав - то 2 гигабайта).
Упираетесь Вы, конечно, не в систему, а в innodb_buffer_pool_size - поставьте значение
побольше.
Неактивен
Спасибо за ответ.
Всё с точностью до наоборот. Поставил максимум который дала операционка - 1,4 Гб, ошибка стала вылетать через 2 минуты работы. Поставил 500Мб, вылетит наверное всё равно через некоторое время. Может где память не освобождается? хотя эти вставки делаем коннекшн закрываем после каждой операции. Не понятно. По поводу второго вопроса есть мысли?
Вопрос№2: Периодически при инсерте этот процесс зависает на 40 секунд, обычно до секунды. При чем это происходит в последние 2 секунды, например в 09:52:59 или 19:07:58, что это?
Неактивен
А как Вы оцениваете "максимум, который дала операционка"? Учтите, что помимо
памяти InnoDB, серверу еще нужно памяти для других вещей (например, для сортировки
индексов, для хранения MyISAM-ключей и т.д.) - Вы можете упереться в ошибку
выделения памяти совсем на другом этапе.
Не поленился и залез на микрософт, чтобы узнать, во что же Вы все-таки упираетесь 
http://msdn.microsoft.com/en-us/library/aa366778.aspx
2 GB на процесс. Что удивительно - в 64битной версии Windows - тоже 2GB на процесс!
Итого, Вы действительно уперлись в ограничения ОС 
Возможно, стоит посмотреть, какие буферы Вы не используете (например, может оказаться
так, что все Ваши таблички InnoDB - тогда нет смысла держать большой key_buffer_size,
он все равно не будет использоваться. Аналогично, query_cache и sort_buffer_size (размер
устанавливается на каждое соединение, так что может оказаться тоже большим).
Обычно в такой ситуации я рекомендую переходить на 64битную версию ОС, но в свете
свежеприобретенных знаний, советую переходить на 64-битную UNIX-платформу, там таких
ограничений нет в принципе.
Неактивен
Спасибо за ответ.
"Максимум который дала операционка" - это когда запускался сервер мускула, если больше, то писал что-то типа: InnoDB: "Operating system error number 3 in a file operation." Да вроде нашли заплатку выделения 3Гб под процесс (в boot.ini прописывается), всё равно не помогает. Пока пришли к выводу действительно попробывать на unix переходить (только для нас это темный лес). Какую посоветуете 64битный unix систему? (свободнораспространяемую) . А на 32 битном unix есть ограничения? А то 30 серваков, не на все поставишь 64.
Неактивен
Можно CentOS 5 поставить, нормально работает и MySQL для нее официальные бинарники есть (те, которые под Red Hat Enterprise Linux).
Ограничение в 32-битном линуксе 3 или 4 гига.
Неактивен
