high log flush wait

I am seeing what appears to be file contention in the
form of log flush waits (consistently longer than 1/sec).
Other than separating the .ldf and .mdf on different
physical devices, is there anything that can be done to
minimize this?
TIA,
AJSeparating the devices is precisely what you should do. Your problem
clearly demonstrates why the recommendation exists in the first place.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"AJ" <anonymous@.discussions.microsoft.com> wrote in message
news:423501c49030$78833070$a601280a@.phx.gbl...
> I am seeing what appears to be file contention in the
> form of log flush waits (consistently longer than 1/sec).
> Other than separating the .ldf and .mdf on different
> physical devices, is there anything that can be done to
> minimize this?
> TIA,
> AJ|||Is there really nothing else that can be done?
I have PLANS to separate them, but I have to wait for new
hardware to arrive. In the meantime, performance is
seriously suffering. Any additional suggestions would be
MOST appreciated.
AJ
>--Original Message--
>Separating the devices is precisely what you should do.
Your problem
>clearly demonstrates why the recommendation exists in
the first place.
>--
>Geoff N. Hiten
>Microsoft SQL Server MVP
>Senior Database Administrator
>Careerbuilder.com
>I support the Professional Association for SQL Server
>www.sqlpass.org
>"AJ" <anonymous@.discussions.microsoft.com> wrote in
message
>news:423501c49030$78833070$a601280a@.phx.gbl...
1/sec).[vbcol=seagreen]
>
>.
>|||You can try and see if there are other performance limitations on your
system, but high log flush wait times won't get better without faster
hardware.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"AJ" <anonymous@.discussions.microsoft.com> wrote in message
news:0aa401c4903b$c7b032a0$a401280a@.phx.gbl...[vbcol=seagreen]
> Is there really nothing else that can be done?
> I have PLANS to separate them, but I have to wait for new
> hardware to arrive. In the meantime, performance is
> seriously suffering. Any additional suggestions would be
> MOST appreciated.
> AJ
> Your problem
> the first place.
> message
> 1/sec).

high log flush wait

I am seeing what appears to be file contention in the
form of log flush waits (consistently longer than 1/sec).
Other than separating the .ldf and .mdf on different
physical devices, is there anything that can be done to
minimize this?
TIA,
AJSeparating the devices is precisely what you should do. Your problem
clearly demonstrates why the recommendation exists in the first place.
--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"AJ" <anonymous@.discussions.microsoft.com> wrote in message
news:423501c49030$78833070$a601280a@.phx.gbl...
> I am seeing what appears to be file contention in the
> form of log flush waits (consistently longer than 1/sec).
> Other than separating the .ldf and .mdf on different
> physical devices, is there anything that can be done to
> minimize this?
> TIA,
> AJ|||Is there really nothing else that can be done?
I have PLANS to separate them, but I have to wait for new
hardware to arrive. In the meantime, performance is
seriously suffering. Any additional suggestions would be
MOST appreciated.
AJ
>--Original Message--
>Separating the devices is precisely what you should do.
Your problem
>clearly demonstrates why the recommendation exists in
the first place.
>--
>Geoff N. Hiten
>Microsoft SQL Server MVP
>Senior Database Administrator
>Careerbuilder.com
>I support the Professional Association for SQL Server
>www.sqlpass.org
>"AJ" <anonymous@.discussions.microsoft.com> wrote in
message
>news:423501c49030$78833070$a601280a@.phx.gbl...
>> I am seeing what appears to be file contention in the
>> form of log flush waits (consistently longer than
1/sec).
>> Other than separating the .ldf and .mdf on different
>> physical devices, is there anything that can be done to
>> minimize this?
>> TIA,
>> AJ
>
>.
>|||You can try and see if there are other performance limitations on your
system, but high log flush wait times won't get better without faster
hardware.
--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"AJ" <anonymous@.discussions.microsoft.com> wrote in message
news:0aa401c4903b$c7b032a0$a401280a@.phx.gbl...
> Is there really nothing else that can be done?
> I have PLANS to separate them, but I have to wait for new
> hardware to arrive. In the meantime, performance is
> seriously suffering. Any additional suggestions would be
> MOST appreciated.
> AJ
> >--Original Message--
> >Separating the devices is precisely what you should do.
> Your problem
> >clearly demonstrates why the recommendation exists in
> the first place.
> >
> >--
> >Geoff N. Hiten
> >Microsoft SQL Server MVP
> >Senior Database Administrator
> >Careerbuilder.com
> >
> >I support the Professional Association for SQL Server
> >www.sqlpass.org
> >
> >"AJ" <anonymous@.discussions.microsoft.com> wrote in
> message
> >news:423501c49030$78833070$a601280a@.phx.gbl...
> >> I am seeing what appears to be file contention in the
> >> form of log flush waits (consistently longer than
> 1/sec).
> >>
> >> Other than separating the .ldf and .mdf on different
> >> physical devices, is there anything that can be done to
> >> minimize this?
> >>
> >> TIA,
> >> AJ
> >
> >
> >.
> >

high log flush wait

I am seeing what appears to be file contention in the
form of log flush waits (consistently longer than 1/sec).
Other than separating the .ldf and .mdf on different
physical devices, is there anything that can be done to
minimize this?
TIA,
AJ
Separating the devices is precisely what you should do. Your problem
clearly demonstrates why the recommendation exists in the first place.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"AJ" <anonymous@.discussions.microsoft.com> wrote in message
news:423501c49030$78833070$a601280a@.phx.gbl...
> I am seeing what appears to be file contention in the
> form of log flush waits (consistently longer than 1/sec).
> Other than separating the .ldf and .mdf on different
> physical devices, is there anything that can be done to
> minimize this?
> TIA,
> AJ
|||Is there really nothing else that can be done?
I have PLANS to separate them, but I have to wait for new
hardware to arrive. In the meantime, performance is
seriously suffering. Any additional suggestions would be
MOST appreciated.
AJ
>--Original Message--
>Separating the devices is precisely what you should do.
Your problem
>clearly demonstrates why the recommendation exists in
the first place.
>--
>Geoff N. Hiten
>Microsoft SQL Server MVP
>Senior Database Administrator
>Careerbuilder.com
>I support the Professional Association for SQL Server
>www.sqlpass.org
>"AJ" <anonymous@.discussions.microsoft.com> wrote in
message[vbcol=seagreen]
>news:423501c49030$78833070$a601280a@.phx.gbl...
1/sec).
>
>.
>
|||You can try and see if there are other performance limitations on your
system, but high log flush wait times won't get better without faster
hardware.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"AJ" <anonymous@.discussions.microsoft.com> wrote in message
news:0aa401c4903b$c7b032a0$a401280a@.phx.gbl...[vbcol=seagreen]
> Is there really nothing else that can be done?
> I have PLANS to separate them, but I have to wait for new
> hardware to arrive. In the meantime, performance is
> seriously suffering. Any additional suggestions would be
> MOST appreciated.
> AJ
> Your problem
> the first place.
> message
> 1/sec).

High buffer cache hit ration but low page life expectancy

I've noticed that I have a buffer cache hit ratio consistently around
99% but a page life expectancy chronically below the 300 second level.
I'm wondering how this is possible? Presumably the page life
expectancy is low because the buffer pool needs to clear out pages to
make room for new pages but why would it need to do this if the cache
hit ratio is around 100%?
ThanksHow about the read-ahead manager putting asked for data into ram (thus
forcing out 'old' data) before it is actually needed by various SELECT
statements? Also buffer cache hit ratio and page life expectancy could be
calculated on different time schedules internally which could account for
their apparent disparity.
TheSQLGuru
President
Indicium Resources, Inc.
<pshroads@.gmail.com> wrote in message
news:1177626752.644290.325550@.s33g2000prh.googlegroups.com...
> I've noticed that I have a buffer cache hit ratio consistently around
> 99% but a page life expectancy chronically below the 300 second level.
> I'm wondering how this is possible? Presumably the page life
> expectancy is low because the buffer pool needs to clear out pages to
> make room for new pages but why would it need to do this if the cache
> hit ratio is around 100%?
> Thanks
>|||Hi
"pshroads@.gmail.com" wrote:

> I've noticed that I have a buffer cache hit ratio consistently around
> 99% but a page life expectancy chronically below the 300 second level.
> I'm wondering how this is possible? Presumably the page life
> expectancy is low because the buffer pool needs to clear out pages to
> make room for new pages but why would it need to do this if the cache
> hit ratio is around 100%?
> Thanks
>
Check out
http://download.microsoft.com/downl...aits_Queues.doc
A low page life expectancy with a high checkpoint pages/sec and lazy
write/sec values would indicate memory pressure. Also check for missing
indexes.
John

High buffer cache hit ration but low page life expectancy

I've noticed that I have a buffer cache hit ratio consistently around
99% but a page life expectancy chronically below the 300 second level.
I'm wondering how this is possible? Presumably the page life
expectancy is low because the buffer pool needs to clear out pages to
make room for new pages but why would it need to do this if the cache
hit ratio is around 100%?
ThanksHow about the read-ahead manager putting asked for data into ram (thus
forcing out 'old' data) before it is actually needed by various SELECT
statements? Also buffer cache hit ratio and page life expectancy could be
calculated on different time schedules internally which could account for
their apparent disparity.
--
TheSQLGuru
President
Indicium Resources, Inc.
<pshroads@.gmail.com> wrote in message
news:1177626752.644290.325550@.s33g2000prh.googlegroups.com...
> I've noticed that I have a buffer cache hit ratio consistently around
> 99% but a page life expectancy chronically below the 300 second level.
> I'm wondering how this is possible? Presumably the page life
> expectancy is low because the buffer pool needs to clear out pages to
> make room for new pages but why would it need to do this if the cache
> hit ratio is around 100%?
> Thanks
>|||Hi
"pshroads@.gmail.com" wrote:
> I've noticed that I have a buffer cache hit ratio consistently around
> 99% but a page life expectancy chronically below the 300 second level.
> I'm wondering how this is possible? Presumably the page life
> expectancy is low because the buffer pool needs to clear out pages to
> make room for new pages but why would it need to do this if the cache
> hit ratio is around 100%?
> Thanks
>
Check out
http://download.microsoft.com/download/4/7/a/47a548b9-249e-484c-abd7-29f31282b04d/Performance_Tuning_Waits_Queues.doc
A low page life expectancy with a high checkpoint pages/sec and lazy
write/sec values would indicate memory pressure. Also check for missing
indexes.
John