Before we start re-architecting the whole insides of XRootD, be aware that the model we use is run-to-completion which is usually the best one in the type of workflows we see most often. That means that thread pools provide limited improvement (actually almost none) this is because we need a thread to just service the socket and once we have it doesn’t matter what we do with it. In this kind of model thread priority would be far more effective. Unfortunately, Linux doesn’t seem to do a good job honoring the priority (well it didn’t some time ago so we don’t bother using it). In general, if you have a server that is bogged down then the way to properly solve this is to bring up another server to balance out the load.<br>
<br>
Andy<br>
<br>
From: Adrian Sevcenco <br>
Sent: Thursday, March 14, 2019 4:50 AM<br>
To: xrootd/xrootd <br>
Cc: Subscribed <br>
Subject: Re: [xrootd/xrootd] Reserve threads for metadata and status operations (#927)<br>
<br>
well, 0 resource i meant that thread allocation time is on the order of ms to s in contrast to thousands (or maxt number) of transfers that block any other query to xrootd server. so, even with auth it is (should be) ok if the operations are of the status type xrdfs query config and xrdfs query stats and mostly ok for metadata type operations : xrdfs stat, xrdfs statvfs, xrdfs query space, xrdfs query xattr and xrdfs ls)<br>
<br>
—<br>
You are receiving this because you are subscribed to this thread.<br>
Reply to this email directly, view it on GitHub, or mute the thread.<br>


<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/xrootd/xrootd/issues/927#issuecomment-473068227">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AD7YjhF2SqC8jBEvo0j84Cds-W_dYPTzks5vWr1MgaJpZM4bztep">mute the thread</a>.<img src="https://github.com/notifications/beacon/AD7YjjEotS_28xp_XDtCJSYKEp1Pzm6pks5vWr1MgaJpZM4bztep.gif" height="1" width="1" alt="" /></p>
<!cript type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/xrootd/xrootd","title":"xrootd/xrootd","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/xrootd/xrootd"}},"updates":{"snippets":[{"icon":"PERSON","message":"@abh3 in #927: Before we start re-architecting the whole insides of XRootD, be aware that the model we use is run-to-completion which is usually the best one in the type of workflows we see most often. That means that thread pools provide limited improvement (actually almost none) this is because we need a thread to just service the socket and once we have it doesn’t matter what we do with it. In this kind of model thread priority would be far more effective. Unfortunately, Linux doesn’t seem to do a good job honoring the priority (well it didn’t some time ago so we don’t bother using it). In general, if you have a server that is bogged down then the way to properly solve this is to bring up another server to balance out the load.\n\nAndy\n\nFrom: Adrian Sevcenco \nSent: Thursday, March 14, 2019 4:50 AM\nTo: xrootd/xrootd \nCc: Subscribed \nSubject: Re: [xrootd/xrootd] Reserve threads for metadata and status operations (#927)\n\nwell, 0 resource i meant that thread allocation time is on the order of ms to s in contrast to thousands (or maxt number) of transfers that block any other query to xrootd server. so, even with auth it is (should be) ok if the operations are of the status type xrdfs query config and xrdfs query stats and mostly ok for metadata type operations : xrdfs stat, xrdfs statvfs, xrdfs query space, xrdfs query xattr and xrdfs ls)\n\n—\nYou are receiving this because you are subscribed to this thread.\nReply to this email directly, view it on GitHub, or mute the thread.\n"}],"action":{"name":"View Issue","url":"https://github.com/xrootd/xrootd/issues/927#issuecomment-473068227"}}}</script>
<!cript type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/xrootd/xrootd/issues/927#issuecomment-473068227",
"url": "https://github.com/xrootd/xrootd/issues/927#issuecomment-473068227",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script><br>
<hr>
<p align="left">
Use REPLY-ALL to reply to list</p>
<p align="center">To unsubscribe from the XROOTD-DEV list, click the following link:<br>
<a href="https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1" target="_blank">https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1</a>
</p>