High disk reponse time every Saturday starting at 8 am
I have a server running Microsoft windows server 2012 R2 and it has a very odd problem.
Every week on Saturday starting around 8 am the disk reponse time goes up to over 1000ms, every other day of the week this problem does not seem to surface.
I've been trying to find the cause of this issue for a few weeks now but I am not able to pinpoint it.
The server is a:
Dell PowerEdge R410
2x 2.26 Ghz (6 core) Intel Xeon L5460
2X 16 GB DDR 3
Perc h700 raid controller
4x 3TB 7.2K 3.5"
Raid 5 (3 disk) + 1 disk hot spare
The server is running the following roles/software:
Active Directory
IIS
Cache
(Cache is a software package by intersystems)
If any more information is required please let me know
The problem is surfacing at the moment of writing, any help our tips would be highly appreciated.
hard-drive performance windows-server-2012-r2 windows-server
asked Dec 29 '18 at 8:47
Edo PostEdo Post
973
add a comment |
I have a server running Microsoft windows server 2012 R2 and it has a very odd problem.
Every week on Saturday starting around 8 am the disk reponse time goes up to over 1000ms, every other day of the week this problem does not seem to surface.
I've been trying to find the cause of this issue for a few weeks now but I am not able to pinpoint it.
The server is a:
Dell PowerEdge R410
2x 2.26 Ghz (6 core) Intel Xeon L5460
2X 16 GB DDR 3
Perc h700 raid controller
4x 3TB 7.2K 3.5"
Raid 5 (3 disk) + 1 disk hot spare
The server is running the following roles/software:
Active Directory
IIS
Cache
(Cache is a software package by intersystems)
If any more information is required please let me know
The problem is surfacing at the moment of writing, any help our tips would be highly appreciated.
hard-drive performance windows-server-2012-r2 windows-server
asked Dec 29 '18 at 8:47
Edo PostEdo Post
973
add a comment |
I have a server running Microsoft windows server 2012 R2 and it has a very odd problem.
Every week on Saturday starting around 8 am the disk reponse time goes up to over 1000ms, every other day of the week this problem does not seem to surface.
I've been trying to find the cause of this issue for a few weeks now but I am not able to pinpoint it.
The server is a:
Dell PowerEdge R410
2x 2.26 Ghz (6 core) Intel Xeon L5460
2X 16 GB DDR 3
Perc h700 raid controller
4x 3TB 7.2K 3.5"
Raid 5 (3 disk) + 1 disk hot spare
The server is running the following roles/software:
Active Directory
IIS
Cache
(Cache is a software package by intersystems)
If any more information is required please let me know
The problem is surfacing at the moment of writing, any help our tips would be highly appreciated.
hard-drive performance windows-server-2012-r2 windows-server
asked Dec 29 '18 at 8:47
Edo PostEdo Post
973
I have a server running Microsoft windows server 2012 R2 and it has a very odd problem.
Every week on Saturday starting around 8 am the disk reponse time goes up to over 1000ms, every other day of the week this problem does not seem to surface.
I've been trying to find the cause of this issue for a few weeks now but I am not able to pinpoint it.
The server is a:
Dell PowerEdge R410
2x 2.26 Ghz (6 core) Intel Xeon L5460
2X 16 GB DDR 3
Perc h700 raid controller
4x 3TB 7.2K 3.5"
Raid 5 (3 disk) + 1 disk hot spare
The server is running the following roles/software:
Active Directory
IIS
Cache
(Cache is a software package by intersystems)
If any more information is required please let me know
The problem is surfacing at the moment of writing, any help our tips would be highly appreciated.
hard-drive performance windows-server-2012-r2 windows-server
hard-drive performance windows-server-2012-r2 windows-server
asked Dec 29 '18 at 8:47
Edo PostEdo Post
973
asked Dec 29 '18 at 8:47
Edo PostEdo Post
973
edited Dec 29 '18 at 9:01
Edo Post
asked Dec 29 '18 at 8:47
Edo PostEdo Post
973
asked Dec 29 '18 at 8:47
Edo PostEdo Post
973
asked Dec 29 '18 at 8:47
Edo PostEdo Post
973
973
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Sounds like you are using the Dell PERC Patrol Read [archive] feature.
From the article:
Patrol Read automatically runs every seven days on configured SAS and SATA HDDs.
If you have low I/O on Saturday at 8 AM, Patrol Read would run at a higher priority and may cause the disk response time to spike. Supposedly, if you increased your I/O usage, Patrol Read would back off to let you perform your I/O activity:
Patrol Read adjusts the amount of controller resources dedicated to Patrol Read operations based on outstanding disk I/O. For example, if the system is busy processing I/O operation, then Patrol Read uses fewer resources to allow the I/O to take a higher priority.
If you want consistent performance, you can try turning Patrol Read off, but in the future, bad sectors may begin to lurk in infrequently accessed areas of affected disks, which may hurt your RAID 5 recovery chances.
As for how to configure Patrol Read:
Patrol Read Mode can be set in BIOS configuration utility and UEFI RAID Configuration Utility.
answered Dec 29 '18 at 9:10
DeltikDeltik
12.7k144486
Looks like patrol read was indeed running and starting at Saturdays at 8am sharp. I stopped it for now, going to keep monitoring the response times (highest at the moment is 15 ms which is great) and change the sceduale to start at Saturday night instead. It looks like the small file acces Cache does (up to 8kb per file io) was not registering with patrol reads "Activity" and it just kept going. It was a feature I had no knowledge of, but it sure seems like it was causing the disk slowdown. You my friend, are a hero
– Edo Post
Dec 29 '18 at 9:42
Also, i was able to configure patrol read through the perc cli
– Edo Post
Dec 29 '18 at 10:07
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1388690%2fhigh-disk-reponse-time-every-saturday-starting-at-8-am%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sounds like you are using the Dell PERC Patrol Read [archive] feature.
From the article:
Patrol Read automatically runs every seven days on configured SAS and SATA HDDs.
If you have low I/O on Saturday at 8 AM, Patrol Read would run at a higher priority and may cause the disk response time to spike. Supposedly, if you increased your I/O usage, Patrol Read would back off to let you perform your I/O activity:
Patrol Read adjusts the amount of controller resources dedicated to Patrol Read operations based on outstanding disk I/O. For example, if the system is busy processing I/O operation, then Patrol Read uses fewer resources to allow the I/O to take a higher priority.
If you want consistent performance, you can try turning Patrol Read off, but in the future, bad sectors may begin to lurk in infrequently accessed areas of affected disks, which may hurt your RAID 5 recovery chances.
As for how to configure Patrol Read:
Patrol Read Mode can be set in BIOS configuration utility and UEFI RAID Configuration Utility.
answered Dec 29 '18 at 9:10
DeltikDeltik
12.7k144486
Looks like patrol read was indeed running and starting at Saturdays at 8am sharp. I stopped it for now, going to keep monitoring the response times (highest at the moment is 15 ms which is great) and change the sceduale to start at Saturday night instead. It looks like the small file acces Cache does (up to 8kb per file io) was not registering with patrol reads "Activity" and it just kept going. It was a feature I had no knowledge of, but it sure seems like it was causing the disk slowdown. You my friend, are a hero
– Edo Post
Dec 29 '18 at 9:42
Also, i was able to configure patrol read through the perc cli
– Edo Post
Dec 29 '18 at 10:07
add a comment |
Sounds like you are using the Dell PERC Patrol Read [archive] feature.
From the article:
Patrol Read automatically runs every seven days on configured SAS and SATA HDDs.
If you have low I/O on Saturday at 8 AM, Patrol Read would run at a higher priority and may cause the disk response time to spike. Supposedly, if you increased your I/O usage, Patrol Read would back off to let you perform your I/O activity:
Patrol Read adjusts the amount of controller resources dedicated to Patrol Read operations based on outstanding disk I/O. For example, if the system is busy processing I/O operation, then Patrol Read uses fewer resources to allow the I/O to take a higher priority.
If you want consistent performance, you can try turning Patrol Read off, but in the future, bad sectors may begin to lurk in infrequently accessed areas of affected disks, which may hurt your RAID 5 recovery chances.
As for how to configure Patrol Read:
Patrol Read Mode can be set in BIOS configuration utility and UEFI RAID Configuration Utility.
answered Dec 29 '18 at 9:10
DeltikDeltik
12.7k144486
Looks like patrol read was indeed running and starting at Saturdays at 8am sharp. I stopped it for now, going to keep monitoring the response times (highest at the moment is 15 ms which is great) and change the sceduale to start at Saturday night instead. It looks like the small file acces Cache does (up to 8kb per file io) was not registering with patrol reads "Activity" and it just kept going. It was a feature I had no knowledge of, but it sure seems like it was causing the disk slowdown. You my friend, are a hero
– Edo Post
Dec 29 '18 at 9:42
Also, i was able to configure patrol read through the perc cli
– Edo Post
Dec 29 '18 at 10:07
add a comment |
Sounds like you are using the Dell PERC Patrol Read [archive] feature.
From the article:
Patrol Read automatically runs every seven days on configured SAS and SATA HDDs.
If you have low I/O on Saturday at 8 AM, Patrol Read would run at a higher priority and may cause the disk response time to spike. Supposedly, if you increased your I/O usage, Patrol Read would back off to let you perform your I/O activity:
Patrol Read adjusts the amount of controller resources dedicated to Patrol Read operations based on outstanding disk I/O. For example, if the system is busy processing I/O operation, then Patrol Read uses fewer resources to allow the I/O to take a higher priority.
If you want consistent performance, you can try turning Patrol Read off, but in the future, bad sectors may begin to lurk in infrequently accessed areas of affected disks, which may hurt your RAID 5 recovery chances.
As for how to configure Patrol Read:
Patrol Read Mode can be set in BIOS configuration utility and UEFI RAID Configuration Utility.
answered Dec 29 '18 at 9:10
DeltikDeltik
12.7k144486
Sounds like you are using the Dell PERC Patrol Read [archive] feature.
From the article:
Patrol Read automatically runs every seven days on configured SAS and SATA HDDs.
If you have low I/O on Saturday at 8 AM, Patrol Read would run at a higher priority and may cause the disk response time to spike. Supposedly, if you increased your I/O usage, Patrol Read would back off to let you perform your I/O activity:
Patrol Read adjusts the amount of controller resources dedicated to Patrol Read operations based on outstanding disk I/O. For example, if the system is busy processing I/O operation, then Patrol Read uses fewer resources to allow the I/O to take a higher priority.
If you want consistent performance, you can try turning Patrol Read off, but in the future, bad sectors may begin to lurk in infrequently accessed areas of affected disks, which may hurt your RAID 5 recovery chances.
As for how to configure Patrol Read:
Patrol Read Mode can be set in BIOS configuration utility and UEFI RAID Configuration Utility.
answered Dec 29 '18 at 9:10
DeltikDeltik
12.7k144486
answered Dec 29 '18 at 9:10
DeltikDeltik
12.7k144486
answered Dec 29 '18 at 9:10
DeltikDeltik
12.7k144486
answered Dec 29 '18 at 9:10
DeltikDeltik
12.7k144486
12.7k144486
Looks like patrol read was indeed running and starting at Saturdays at 8am sharp. I stopped it for now, going to keep monitoring the response times (highest at the moment is 15 ms which is great) and change the sceduale to start at Saturday night instead. It looks like the small file acces Cache does (up to 8kb per file io) was not registering with patrol reads "Activity" and it just kept going. It was a feature I had no knowledge of, but it sure seems like it was causing the disk slowdown. You my friend, are a hero
– Edo Post
Dec 29 '18 at 9:42
Also, i was able to configure patrol read through the perc cli
– Edo Post
Dec 29 '18 at 10:07
add a comment |
Looks like patrol read was indeed running and starting at Saturdays at 8am sharp. I stopped it for now, going to keep monitoring the response times (highest at the moment is 15 ms which is great) and change the sceduale to start at Saturday night instead. It looks like the small file acces Cache does (up to 8kb per file io) was not registering with patrol reads "Activity" and it just kept going. It was a feature I had no knowledge of, but it sure seems like it was causing the disk slowdown. You my friend, are a hero
– Edo Post
Dec 29 '18 at 9:42
Also, i was able to configure patrol read through the perc cli
– Edo Post
Dec 29 '18 at 10:07
Looks like patrol read was indeed running and starting at Saturdays at 8am sharp. I stopped it for now, going to keep monitoring the response times (highest at the moment is 15 ms which is great) and change the sceduale to start at Saturday night instead. It looks like the small file acces Cache does (up to 8kb per file io) was not registering with patrol reads "Activity" and it just kept going. It was a feature I had no knowledge of, but it sure seems like it was causing the disk slowdown. You my friend, are a hero
– Edo Post
Dec 29 '18 at 9:42
Looks like patrol read was indeed running and starting at Saturdays at 8am sharp. I stopped it for now, going to keep monitoring the response times (highest at the moment is 15 ms which is great) and change the sceduale to start at Saturday night instead. It looks like the small file acces Cache does (up to 8kb per file io) was not registering with patrol reads "Activity" and it just kept going. It was a feature I had no knowledge of, but it sure seems like it was causing the disk slowdown. You my friend, are a hero
– Edo Post
Dec 29 '18 at 9:42
Also, i was able to configure patrol read through the perc cli
– Edo Post
Dec 29 '18 at 10:07
Also, i was able to configure patrol read through the perc cli
– Edo Post
Dec 29 '18 at 10:07
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1388690%2fhigh-disk-reponse-time-every-saturday-starting-at-8-am%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
