Details
-
Bug
-
Status: Closed
-
Major - P3
-
Resolution: Done
-
3.0.6
-
Fully Compatible
-
ALL
Description
This is a spinoff from SERVER-20876. In that ticket we saw in cache full condtions that serverStatus became stuck in this stack trace:
Thread 17 (Thread 0x7f58d3df9700 (LWP 7721)):
|
#0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
|
#1 0x0000000001366e61 in __wt_cond_wait ()
|
#2 0x000000000134cfa7 in __wt_cache_wait ()
|
#3 0x000000000139312d in ?? ()
|
#4 0x0000000000d7c6ad in mongo::WiredTigerRecoveryUnit::_txnOpen(mongo::OperationContext*) ()
|
#5 0x0000000000d7c7ef in mongo::WiredTigerRecoveryUnit::getSession(mongo::OperationContext*) ()
|
#6 0x0000000000d8020b in mongo::WiredTigerServerStatusSection::generateSection(mongo::OperationContext*, mongo::BSONElement const&) const ()
|
#7 0x0000000000974e49 in mongo::CmdServerStatus::run(mongo::OperationContext*, std::string const&, mongo::BSONObj&, int, std::string&, mongo::BSONObjBuilder&, bool) ()
|
#8 0x00000000009bdc64 in mongo::_execCommand(mongo::OperationContext*, mongo::Command*, std::string const&, mongo::BSONObj&, int, std::string&, mongo::BSONObjBuilder&, bool) ()
|
#9 0x00000000009bebed in mongo::Command::execCommand(mongo::OperationContext*, mongo::Command*, int, char const*, mongo::BSONObj&, mongo::BSONObjBuilder&, bool) ()
|
#10 0x00000000009bf8fb in mongo::_runCommands(mongo::OperationContext*, char const*, mongo::BSONObj&, mongo::_BufBuilder<mongo::TrivialAllocator>&, mongo::BSONObjBuilder&, bool, int) ()
|
#11 0x0000000000b9340a in mongo::runQuery(mongo::OperationContext*, mongo::Message&, mongo::QueryMessage&, mongo::NamespaceString const&, mongo::CurOp&, mongo::Message&) ()
|
#12 0x0000000000aa3480 in mongo::assembleResponse(mongo::OperationContext*, mongo::Message&, mongo::DbResponse&, mongo::HostAndPort const&) ()
|
#13 0x00000000007e99fd in mongo::MyMessageHandler::process(mongo::Message&, mongo::AbstractMessagingPort*, mongo::LastError*) ()
|
#14 0x0000000000f1badb in mongo::PortMessageServer::handleIncomingMsg(void*) ()
|
#15 0x00007f58d99c6182 in start_thread (arg=0x7f58d3df9700) at pthread_create.c:312
|
#16 0x00007f58d8ac747d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
|
This means that unfortunately no useful diagnostic data could be collected after the cache became full. Ideally serverStatus should succeed regardless of the state of the WT cache.
Attachments
Issue Links
- is related to
-
SERVER-20876 Hang in scenario with sharded ttl collection under WiredTiger
-
- Closed
-
- related to
-
SERVER-20961 Large amounts of create and drop collections can cause listDatabases to be slow under WiredTiger
-
- Closed
-