Mysql_real_query висит в многопоточном приложении Quickfix [закрыто] ⇐ C++

[Anonymous]

У нас есть простое приложение QuickFix, которое переводит исправления сообщений в наш собственный внутренний формат и наоборот.
состоит из двух потоков, одним из которых является Fix :: Application и Fix :: MessageCracker , а другая потока обрабатывает вход со стороны внутренней сети. как QuickFix использует для MySQLSTORE. Если DB находится под слишком большим стрессом, я ожидаю, что каждое отдельное исполнение будет постепенно дольше, но все равно должно закончить. Код или сигнал. Приложение Fix пытается сейф всех сообщений в своем магазине DB. Когда внутренний процесс выполняется, он отправляет обновление обратно в этот процесс, который переводит его обратно в сообщение о ответе Fix. Я не могу себе представить, что мы первыми попробовали это, но я не мог найти ничего, связанного с Googeling. < /P>
Вот типичный след стека. Как вы можете увидеть приложение Fix, пытается вставить новое сообщение в БД. Другие темы ничего не делают. Я отредактировал некоторые конфиденциальные данные из него. < /P>

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

(gdb) info threads
Id   Target Id         Frame
8    Thread 0x7f9689a8e700 (LWP 27627) "tgfix" 0x00007f968b7e09a3 in select () from /lib64/libc.so.6
7    Thread 0x7f968928d700 (LWP 27630) "tgfix" 0x00007f968b7b085d in nanosleep () from /lib64/libc.so.6
6    Thread 0x7f9688879700 (LWP 27664) "tgfix" 0x00007f968b7e09a3 in select () from /lib64/libc.so.6
5    Thread 0x7f967bfff700 (LWP 27665) "tgfix" 0x00007f968d0da75d in read () from /lib64/libpthread.so.0
4    Thread 0x7f967a5f5700 (LWP 10882) "tgfix" 0x00007f968b7b085d in nanosleep () from /lib64/libc.so.6
3    Thread 0x7f967b7fe700 (LWP 10883) "tgfix" 0x00007f968b7b085d in nanosleep () from /lib64/libc.so.6
2    Thread 0x7f967affd700 (LWP 10884) "tgfix" 0x00007f968d0d9b3b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0
* 1    Thread 0x7f968e82f880 (LWP 27626) "tgfix"  0x00007f968d0d9b3b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0
(gdb) t 5
[Switching to thread 5 (Thread 0x7f967bfff700 (LWP 27665))]
#0  0x00007f968d0da75d in read () from /lib64/libpthread.so.0
(gdb) bt
#0  0x00007f968d0da75d in read () from /lib64/libpthread.so.0
#1  0x00007f968e176d20 in vio_read () from /usr/lib64/mysql/libmysqlclient.so.18
#2  0x00007f968e176da1 in vio_read_buff () from /usr/lib64/mysql/libmysqlclient.so.18
#3  0x00007f968e15af3a in my_real_read(st_net*, unsigned long*) () from /usr/lib64/mysql/libmysqlclient.so.18
#4  0x00007f968e15bdac in my_net_read () from /usr/lib64/mysql/libmysqlclient.so.18
#5  0x00007f968e14e84c in cli_safe_read () from /usr/lib64/mysql/libmysqlclient.so.18
#6  0x00007f968e14fe1b in cli_read_query_result () from /usr/lib64/mysql/libmysqlclient.so.18
#7  0x00007f968e151056 in mysql_real_query () from /usr/lib64/mysql/libmysqlclient.so.18
#8  0x00000000004267d6 in MySql::Database::execute (this=this@entry=0x7fffd9eaacf8,
sql="insert into tg_messages_in (beginstring,sendercompid,targetcompid,session_qualifier,msgseqnum,clordid,message) values ('FIX.4.2', '', 'CUSTOMER', '', 1917, 'fix_1757507653635360943_1916', '8="...) at mysql.cpp:155
#9  0x000000000041f8f3 in FixApplication::persistLocally (this=this@entry=0x7fffd9eaace0, message=..., sessionid=...) at fixapplication.cpp:96
#10 0x00000000004209dc in FixApplication::fromApp (this=0x7fffd9eaace0, message=..., sessionid=...) at fixapplication.cpp:57
#11 0x000000000046659f in FIX::Session::verify (this=this@entry=0x1b49d10, msg=..., checkTooHigh=checkTooHigh@entry=true, checkTooLow=checkTooLow@entry=true) at Session.cpp:1159
#12 0x000000000046eaab in FIX::Session::next (this=this@entry=0x1b49d10, message=..., timeStamp=..., queued=queued@entry=false) at Session.cpp:1421
#13 0x000000000046fe8c in FIX::Session::next (this=0x1b49d10,
msg="8=FIX.4.2\001\071=187\001\063\065=D\001\063\064=1917\001\064\071=CUSTOMER\001\065\062=20250910-12:34:13.635\001\065\066=\001\061\061=fix_1757507653635360943_1916\001\061\070=G\001\062\061=1\001\063\070=1\001\064\060=D\001\064\064=999\001\064\070=DE0005439004\001\065\064=1\001\065\065=idontknow\001\066\060=20250910-12:34:13\001\061\060\060=TGO"..., timeStamp=..., queued=queued@entry=false)
at Session.cpp:1339
#14 0x0000000000480bd2 in FIX::SocketConnection::readMessages (this=this@entry=0x7f9674000be0, s=...) at SocketConnection.cpp:224
#15 0x0000000000480dbc in FIX::SocketConnection::read (this=0x7f9674000be0, a=..., s=...) at SocketConnection.cpp:170
#16 0x000000000047d2f1 in FIX::SocketAcceptor::onData (this=0x7fffd9eaafc0, server=..., s=6) at SocketAcceptor.cpp:196
#17 0x00000000004e41d0 in FIX::ServerWrapper::onEvent (this=0x7f967bffed20, monitor=..., socket=6) at SocketServer.cpp:60
#18 0x000000000047f4dc in FIX::SocketMonitor::processReadSet (this=this@entry=0x1baebf0, strategy=..., readSet=...) at SocketMonitor.cpp:260
#19 0x000000000047fa57 in FIX::SocketMonitor::block (this=this@entry=0x1baebf0, strategy=..., poll=poll@entry=false, timeout=timeout@entry=0) at SocketMonitor.cpp:219
#20 0x00000000004e3375 in FIX::SocketServer::block (this=0x1baeb90, strategy=..., poll=poll@entry=false, timeout=timeout@entry=0) at SocketServer.cpp:160
#21 0x000000000047e657 in FIX::SocketAcceptor::onStart (this=0x7fffd9eaafc0) at SocketAcceptor.cpp:113
#22 0x00000000004782fa in FIX::Acceptor::startThread (p=) at Acceptor.cpp:245
#23 0x00007f968d0d3ea5 in start_thread () from /lib64/libpthread.so.0
#24 0x00007f968b7e98dd in clone () from /lib64/libc.so.6

< /code>
Выход мониторинга Innodb выглядит следующим образом: < /p>
| InnoDB |      |
=====================================
250915 10:10:16 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 12 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 76304 1_second, 76304 sleeps, 7454 10_second, 2248 background, 2248 flush
srv_master_thread log flush and writes: 101400
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 14099, signal count 28376
Mutex spin waits 491840, rounds 658978, OS waits 301
RW-shared spins 23695, rounds 208656, OS waits 1749
RW-excl spins 7403, rounds 429165, OS waits 11905
Spin rounds per wait: 1.34 mutex, 8.81 RW-shared, 57.97 RW-excl
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state:  waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (read thread)
I/O thread 6 state: waiting for completed aio requests (write thread)
I/O thread 7 state: waiting for completed aio requests (write thread)
I/O thread 8 state: waiting for completed aio requests (write thread)
I/O thread 9 state: waiting for completed aio requests (write thread)
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
157294 OS file reads, 16750514 OS file writes, 15266644 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
insert 0, delete mark 0, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
Hash table size 276671, node heap has 1 buffer(s)
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 7391011889
Log flushed up to   7391011889
Last checkpoint at  7391009579
Max checkpoint age    7782360
Checkpoint age target 7539162
Modified age          2310
Checkpoint age        2310
0 pending log writes, 0 pending chkp writes
15165146 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 137756672; in additional pool allocated 0
Total memory allocated by read views 488
Internal hash tables (constant factor + variable factor)
Adaptive hash index 2233968     (2213368 + 20600)
Page hash           139112 (buffer pool 0 only)
Dictionary cache    639238  (554768 + 84470)
File system         83536   (82672 + 864)
Lock system         334752  (332872 + 1880)
Recovery system     0   (0 + 0)
Dictionary memory allocated 84470
Buffer pool size        8191
Buffer pool size, bytes 134201344
Free buffers            1
Database pages          8189
Old database pages      3002
Modified db pages       60
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 165713, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 157282, created 101129, written 1523878
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
No buffer pool page gets since the last printout
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 8189, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
0 transactions active inside InnoDB
0 out of 1000 descriptors used
---OLDEST VIEW---
Normal read view
Read view low limit trx n:o 1981E82
Read view up limit trx id 1981E82
Read view low limit trx id 1981E82
Read view individually stored trx ids:
-----------------
Main thread process no. 4985, id 140232077883136, state: flushing log
Number of rows inserted 6202720, updated 8496405, deleted 6104373, read 1884859261
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
------------
TRANSACTIONS
------------
Trx id counter 1981E82
Purge done for trx's n:o < 1981E82 undo n:o < 0
History list length 2241
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 78737, OS thread handle 0x7f8a50df1700, query id 19035242 localhost root
show engine innodb status
---TRANSACTION 1981E80, not started
MySQL thread id 78663, OS thread handle 0x7f8a55755700, query id 19034163 localhost tgfix
---TRANSACTION 1981E7D, not started
MySQL thread id 78662, OS thread handle 0x7f8a5570b700, query id 19034161 localhost tgfix
---TRANSACTION 1980EE3, not started
MySQL thread id 78639, OS thread handle 0x7f8a55755700, query id 19029811 localhost 127.0.0.1 tgfixserver
---TRANSACTION 1980ED9, not started
MySQL thread id 78541, OS thread handle 0x7f8a50df1700, query id 18991418 localhost 127.0.0.1 konfiguration
----------------------------
END OF INNODB MONITOR OUTPUT
============================

Мой неопытный глаз не видит здесь каких -либо крупных красных флагов, за исключением этой строки 1 просмотр, открытые внутри Innodb в операциях строк, о которых я не могу понять. Серверная версия 5.5.65-mariadb , поэтому большая часть схемы производительности еще недоступна. Я не предполагаю, что нашел ошибку в libmysql или libquickfix . Тем не менее, мне было интересно, может ли могущественная сила Интернета сократить мои усилия, чтобы найти ошибку. Комментарии уже дали мне несколько новых идей, где искать. Особенно @Jesper Juhl < /p>
Однако я обнаружил отчет об ошибке с аналогичной жалобой, в которой говорилось, что в определенных обстоятельствах сервер не будет отвечать, и поэтому чтение клиента может зависеть навсегда. Мы расследуем больше по этому поводу, и мы могли бы просто установить тайм -аут и признать, что сервер время от времени не будет отвечать. Если это не правильная комбинация, я был бы рад получить другой вариант.

Подробнее здесь: https://stackoverflow.com/questions/797 ... ickfix-app