From 769bf46a3f4df2ee0dc9167d687a89eaf7547daa Mon Sep 17 00:00:00 2001 From: Nat Goodspeed Date: Wed, 7 Dec 2022 09:50:02 -0500 Subject: SL-14399: Ditch overflow queue LLViewerAssetStorage::mCoroWaitList. mCoroWaitList was introduced to prevent an assertion failure crash: LLCoprocedureManager never expects to fill LLCoprocedurePool::mPendingCoprocs queue. The queue limit was arbitrarily set to 4096 some years ago, but in practice LLViewerAssetStorage can post way more requests than that. LLViewerAssetStorage checked whether the target LLCoprocedureManager pool's queue looked close to full, and if so posted the pending request to its mCoroWaitList instead. But then it had to override the base LLAssetStorage method checkForTimeouts() to continually check whether pending tasks could be moved from mCoroWaitList to LLCoprocedureManager. A simpler solution is to enlarge LLCorpocedureManager::DEFAULT_QUEUE_SIZE, the upper limit on mPendingCoprocs. Since mCoroWaitList was an unlimited queue, making DEFAULT_QUEUE_SIZE "very large" does not increase the risk of runaway memory consumption. --- indra/llmessage/llcoproceduremanager.cpp | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'indra/llmessage') diff --git a/indra/llmessage/llcoproceduremanager.cpp b/indra/llmessage/llcoproceduremanager.cpp index be014e7b1e..d310cefd1e 100644 --- a/indra/llmessage/llcoproceduremanager.cpp +++ b/indra/llmessage/llcoproceduremanager.cpp @@ -47,7 +47,10 @@ static const std::map DefaultPoolSizes{ }; static const U32 DEFAULT_POOL_SIZE = 5; -const U32 LLCoprocedureManager::DEFAULT_QUEUE_SIZE = 4096; +// SL-14399: When we teleport to a brand-new simulator, the coprocedure queue +// gets absolutely slammed with fetch requests. Make this queue effectively +// unlimited. +const U32 LLCoprocedureManager::DEFAULT_QUEUE_SIZE = 1024*1024; //========================================================================= class LLCoprocedurePool: private boost::noncopyable -- cgit v1.2.3 From 8e03f926c787d02d0860a75e9e8fe0f9013df003 Mon Sep 17 00:00:00 2001 From: Andrey Kleshchev Date: Thu, 9 Feb 2023 01:05:14 +0200 Subject: SL-18970 Heavy name cache spam If cap fails viewer can spam hundreds of "get legacy for agent" to logs which freezes it. --- indra/llmessage/llavatarnamecache.cpp | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'indra/llmessage') diff --git a/indra/llmessage/llavatarnamecache.cpp b/indra/llmessage/llavatarnamecache.cpp index 846549b368..87fd5a154f 100644 --- a/indra/llmessage/llavatarnamecache.cpp +++ b/indra/llmessage/llavatarnamecache.cpp @@ -253,7 +253,9 @@ void LLAvatarNameCache::handleAvNameCacheSuccess(const LLSD &data, const LLSD &h { const LLUUID& agent_id = *it; - LL_WARNS("AvNameCache") << "LLAvatarNameResponder::result " + // If cap fails, response can contain a lot of names, + // don't spam too much + LL_DEBUGS("AvNameCache") << "LLAvatarNameResponder::result " << "failed id " << agent_id << LL_ENDL; @@ -272,7 +274,7 @@ void LLAvatarNameCache::handleAgentError(const LLUUID& agent_id) if (existing == mCache.end()) { // there is no existing cache entry, so make a temporary name from legacy - LL_WARNS("AvNameCache") << "LLAvatarNameCache get legacy for agent " + LL_DEBUGS("AvNameCache") << "LLAvatarNameCache get legacy for agent " << agent_id << LL_ENDL; gCacheName->get(agent_id, false, // legacy compatibility boost::bind(&LLAvatarNameCache::legacyNameFetch, _1, _2, _3)); -- cgit v1.2.3