Связь и интернет Архив Программирование
   
Сделать стартовойСделать закладку            
   ПОИСК  
   
Главная / MySQL / Перенос на другие системы /
8  Perl
8  PHP
8  JavaScript
8  HTML
8  DHTML
8  XML
8  CSS
8  C / C++
8  Pascal и Delphi
8  Турбо Ассемблер
8  MySQL
8  CASE-технологии
8  Алгоритмы
8  Python
8  Обратная связь
8  Гостевая книга
Новости о мире


Отладка сервера MySQL - Программирование от RIN.RU
Отладка сервера MySQL



Отладка mysqld при помощи gdb


В большинстве операционных систем можно запускать mysqld под отладчиком gdb - это позволяет получить больше информации при аварийных остановках mysqld,


С некоторыми более старыми версиями gdb под Linux, чтобы обеспечить возможность отладки потоков mysqld, необходимо использовать run --one-thread. В этом случае в каждый момент времени доступен для отладки только один поток. Нам остается только рекомендовать вам как можно быстрее заменить старые версии отладчика на версию gdb 5.1, поскольку отладка
потоков в этой версии работает намного лучше!


При работе mysqld под отладчиком gdb необходимо заблокировать трассировку стеков при помощи --skip-stack-trace, что обеспечит возможность выявить ошибки сегмантацию внутри gdb.


Если постоянно подсоединяются новые пользователи, то отладка MySQL под gdb может оказаться достаточно сложным делом, поскольку gdb не освобождает память, занимаемую старыми потоками. Эту проблему можно устранить, запустив mysqld с параметрами -O thread_cache_size='max_connections+1'. В большинстве случаев даже простое использование -O thread_cache_size=5 может очень помочь!


Для получения дампа оперативной памяти под Linux, если mysqld падает по сигналу SIGSEGV, можно запустить mysqld с опцией --core-file. Этот файл оперативной памяти (core) можно использовать для обратной трассировки при выявлении причин останова mysqld:


shell> gdb mysqld core
gdb> backtrace full
gdb> exit


См. раздел Что делать, если работа MySQL сопровождается постоянными сбоями.


При использовании версии gdb 4.17.x или выше под Linux необходимо установить в текущем каталоге файл '.gdb' со следующей информацией:


set print sevenbit off
handle SIGUSR1 nostop noprint
handle SIGUSR2 nostop noprint
handle SIGWAITING nostop noprint
handle SIGLWP nostop noprint
handle SIGPIPE nostop
handle SIGALRM nostop
handle SIGHUP nostop
handle SIGTERM nostop noprint


Если при отладке потоков с помощью gdb возникают проблемы, необходимо загрузить версию gdb 5.x и попробовать использовать ее вместо прежней. Новая версия отладчика gdb обеспечивает значительно улучшенную обработку потоков!


Ниже приводится пример отладки mysqld:


shell> gdb /usr/local/libexec/mysqld
gdb> run
...
backtrace full # Делайте это при аварийной остановке mysqld


Включите полученный вывод в письмо, сгенерированное с помощью mysqlbug, и пошлите это письмо по адресу mysql@lists.mysql.com.


Если mysqld зависает, можно попробовать использовать некоторые системные средства наподобие strace или /usr/proc/bin/pstack для выяснения, где именно произошло зависание mysqld.


strace /tmp/log libexec/mysqld


Если используется интерфейс Perl DBI, то можно получить отладочную информацию, используя метод trace или установив переменную окружения DBI_TRACE. См. разде Интерфейс DBI.


Использование трассировки стека


В некоторых операционных системах журнал ошибок в случае смерти mysqld будет содержать трассировку стека. Эти данные можно использовать для выяснения, где (и, может быть, почему) умер mysqld (см. раздел Журнал ошибок). Для получения трассировки стека не следует компилировать mysqld с
опцией -fomit-frame-pointer для gcc (см. раздел 1 Компиляция MySQL для отладки).


Если файл ошибок содержит что-нибудь похожее на следующее:


mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died
Attemping backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong
stack range sanity check, ok, backtrace follows
0x40077552
0x81281a0
0x8128f47
0x8127be0
0x8127995
0x8104947
0x80ff28f
0x810131b
0x80ee4bc
0x80c3c91
0x80c6b43
0x80c1fd9
0x80c1686


то можно определить, где произошла остановка mysqld. Для этого нужно выполнить следующие действия:


  1. Скопируйте приведенные выше числовые значения в файл, например mysqld.stack.

  2. Создайте файл символов для сервера mysqld:


    nm -n libexec/mysqld > /tmp/mysqld.sym


    Следует учесть, что во многих бинарных поставках MySQL приведенный выше файл с именем 'mysqld.sym.gz' уже имеется. В этом случае необходимо распаковать его следующим образом:


    gunzip < bin/mysqld.sym.gz > /tmp/mysqld.sym


  3. Выполните resolve_stack_dump -s /tmp/mysqld.sym -n mysqld.stack, чтобы вывести место остановки mysqld. Если и это не поможет определить причину останова mysqld, то следует сделать отчет об ошибке и включить в него данный вывод с комментарием. Следует учитывать, однако, что в большинстве случаев наличие лишь только трассировки стеков не поможет нам определить причину данной проблемы. Чтобы иметь возможность локализовать данный сбой или рекомендовать обходной путь, нам, как правило, необходимо знать, какой именно запрос привел к
    остановке mysqld и, желательно, иметь контрольный пример, чтобы мы могли воспроизвести данную проблему! См. раздел Как отправлять отчеты об ошибках или проблемах.




<<<  НазадВперед  >>>
 1  2  3  4 


 8  Комментарии к статье  8 8  Обсудить в чате

8  В тему

Отладка сервера MySQL

Отладка клиента MySQL

Пакет DBUG

Методы блокировки

Замечания по потокам RTS

Различия между разными потоковыми пакетами

 
  
  
    Copyright ©  RIN 2003 - 2004      * Обратная связь