|
MySQL.RU - Webboard
 Вернуться
 Спасите! Не втягивается огромный MySQL-dupm! (Balancer) 17/02/2004 - 01:01:25
 Re: Спасите! Не втягивается огромный MySQL-dupm! (Sergey) 17/02/2004 - 07:29:34
> Original message text:
> From: Balancer - 17/02/2004 - 01:01:25
> Subject:Спасите! Не втягивается огромный MySQL-dupm!
> -----------------
> В общем, это всё я. Вот уже 18 часов кряду пытаюсь перевести свой форум на UTF8 и, соответственно, MySQL 4.1
>
> В общем, после великого множества мучений, связанного с кодировками, пытаюсь втащить 400-мегабайтный дамп в cp1251, без перекодирвки, сделанный из 4.0.16
>
> Упорно через некоторе время работы:
> ERROR 2013 at line 22578: Lost connection to MySQL server during query
>
> Помогите разобратья, тысяча человек народа сидит, страдает и ждёт :-/
>
> В этой строчке вполне безобидный маленький INSERT, на ~1кБ. Валится стабильно и на одной и той же строке. В логе:
>
> mysqld got signal 11;
> This could be because you hit a bug. It is also possible that this binary
> or one of the libraries it was linked against is corrupt, improperly built,
> or misconfigured. This error can also be caused by malfunctioning hardware.
> We will try our best to scrape up some info that will hopefully help diagnose
> the problem, but since we have already crashed, something is definitely wrong
> and this may fail.
>
> key_buffer_size=16777216
> read_buffer_size=520192
> max_used_connections=1
> max_connections=50
> threads_connected=1
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 67383 K
> bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
>
> thd=0x84da070
> Attempting backtrace. You can use the following information to find out
> where mysqld died. If you see no messages after this, something went
> terribly wrong...
> Cannot determine thread, fp=0x417f5cc8, backtrace may not be correct.
> Stack range sanity check OK, backtrace follows:
> 0x811c628
> 0x40024f05
> ...
> ...
> 0x420e792a
> New value of fp=(nil) failed sanity check, terminating stack trace!
> Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to r
> stack trace is much more helpful in diagnosing the problem, so please do
> resolve it
> Trying to get some variables.
> Some pointers may be invalid and cause the dump to abort...
> thd->query at 0x8536958 = INSERT INTO ib_posts VALUES (0,NULL,17396,'1-2497',1,261,'Flogger-B',1,1
> thd->thread_id=45
> The manual page at http://www.mysql.com/doc/en/Crashing.html contains
> information that should help you find out what is causing the crash.
>
> Number of processes running now: 0
> 040217 00:53:35 mysqld restarted
>
> Linux RH7.3, на винтах места дофига, 2x1800 Xeon, 512RAM.
> my.cnf:
> ...
> [mysqld]
> back_log = 20
> datadir = /usr/local/var
> port = 3306
> socket = /var/lib/mysql/mysql.sock
> skip-locking
> key_buffer = 16M
> max_allowed_packet = 8M
> max_connections = 50
> table_cache = 256
> sort_buffer_size = 512K
> read_buffer_size = 512K
> myisam_sort_buffer_size = 8M
> ...
>
From: Sergey - 17/02/2004 - 07:29:34
Subject:Спасите! Не втягивается огромный MySQL-dupm!
-----------------
альфа батенька
[Это сообщение - спам!]
Последние сообщения из форума
Уважаемые посетители форума MySQL.RU!
Убедительная просьба, прежде чем задавать свой вопрос в этом форуме, обратите внимание на разделы:
- ответы на наиболее часто задаваемые вопросы - FAQ
- раздел документация
- раздел поиск по сообщениям форума и документации
Также, старайтесь наиболее подробно указывать свою ситуацию (версию операционной системы, версию MySQL,
версию программного обеспечения, по которому возникает вопрос, текст возникающих ошибок, и др.)
Помните, чем конкретнее Вы опишете ситуацию, тем больше шансов получить реальную помощь.
13041
|
|
