disk I/O tool
in [Server Configuration]
|
Prev: Create Account
Next: sys.dm_exec_query_stats
From: Jay on 31 Dec 2009 18:48 SQLIO++ will do. I'm in a discussion where a guy is saying msdb is so busy, that local SCSI drives don't have enough throughput and it has to be on the SAN (which is RAID 5 BTW). I was suggesting to him to run SQLIOsim to see what the monitors look like when the drive is hammered and to compare it to what he sees in his production environment. Jay "Andrew J. Kelly" <sqlmvpnooospam(a)shadhawk.com> wrote in message news:OPl$zIiiKHA.5604(a)TK2MSFTNGP04.phx.gbl... > It depends on what you want to accomplish as there are several. Can you > tell us what your goal is? > > -- > > Andrew J. Kelly SQL MVP > Solid Quality Mentors > > "Jay" <spam(a)nospam.org> wrote in message > news:#HfRsQciKHA.1648(a)TK2MSFTNGP05.phx.gbl... >> SQLIOsim, which the spell checker wants to change to Solipsism :) >> >> "Jay" <spam(a)nospam.org> wrote in message >> news:OhTGHEciKHA.1648(a)TK2MSFTNGP05.phx.gbl... >>> What is the name of that disk I/O tool? >>> >> >>
From: Andrew J. Kelly on 1 Jan 2010 09:19 Why would MSDB be that busy? If it really is you might want to see why because it shouldn't be under normal circumstances. SQLIOSIM simulates SQL IO patterns but is not really a measurement tool per say. It is more to hammer the array and see where it breaks. If you want to see how it actually performs in general reads & writes use SQLIO. -- Andrew J. Kelly SQL MVP Solid Quality Mentors "Jay" <spam(a)nospam.org> wrote in message news:OgPyrOniKHA.1536(a)TK2MSFTNGP06.phx.gbl... > SQLIO++ will do. > > I'm in a discussion where a guy is saying msdb is so busy, that local SCSI > drives don't have enough throughput and it has to be on the SAN (which is > RAID 5 BTW). I was suggesting to him to run SQLIOsim to see what the > monitors look like when the drive is hammered and to compare it to what he > sees in his production environment. > > Jay > > "Andrew J. Kelly" <sqlmvpnooospam(a)shadhawk.com> wrote in message > news:OPl$zIiiKHA.5604(a)TK2MSFTNGP04.phx.gbl... >> It depends on what you want to accomplish as there are several. Can you >> tell us what your goal is? >> >> -- >> >> Andrew J. Kelly SQL MVP >> Solid Quality Mentors >> >> "Jay" <spam(a)nospam.org> wrote in message >> news:#HfRsQciKHA.1648(a)TK2MSFTNGP05.phx.gbl... >>> SQLIOsim, which the spell checker wants to change to Solipsism :) >>> >>> "Jay" <spam(a)nospam.org> wrote in message >>> news:OhTGHEciKHA.1648(a)TK2MSFTNGP05.phx.gbl... >>>> What is the name of that disk I/O tool? >>>> >>> >>> > >
From: Jay on 1 Jan 2010 14:06 Sigh, that has basically been my argument. However, the guy has stuck to his guns that his msdb is so active that the local drives aren't enough and that it must be on the SAN for performance reasons. The best I could think of was to stress a similar drive (and monitor it) to show what off the shelf SCSI's can do on an internal controller and that msdb activity just doesn't come close to the drive capacity. Perhaps SQLIO, being simpler, would be better. His DB seems to have a very large number of databases and each of these DB's seem to have a lot of SQL Agent jobs that fire frequently. This combined with heavy Message Broker activity is supposedly generating log writes, reads and I have no clue what, to produce the "heavy activity" that requires the SAN - which is RAID 5 BTW. "Andrew J. Kelly" <sqlmvpnooospam(a)shadhawk.com> wrote in message news:upeu61uiKHA.1236(a)TK2MSFTNGP04.phx.gbl... > Why would MSDB be that busy? If it really is you might want to see why > because it shouldn't be under normal circumstances. SQLIOSIM simulates > SQL IO patterns but is not really a measurement tool per say. It is more > to hammer the array and see where it breaks. If you want to see how it > actually performs in general reads & writes use SQLIO. > > -- > > Andrew J. Kelly SQL MVP > Solid Quality Mentors > > "Jay" <spam(a)nospam.org> wrote in message > news:OgPyrOniKHA.1536(a)TK2MSFTNGP06.phx.gbl... >> SQLIO++ will do. >> >> I'm in a discussion where a guy is saying msdb is so busy, that local >> SCSI drives don't have enough throughput and it has to be on the SAN >> (which is RAID 5 BTW). I was suggesting to him to run SQLIOsim to see >> what the monitors look like when the drive is hammered and to compare it >> to what he sees in his production environment. >> >> Jay >> >> "Andrew J. Kelly" <sqlmvpnooospam(a)shadhawk.com> wrote in message >> news:OPl$zIiiKHA.5604(a)TK2MSFTNGP04.phx.gbl... >>> It depends on what you want to accomplish as there are several. Can you >>> tell us what your goal is? >>> >>> -- >>> >>> Andrew J. Kelly SQL MVP >>> Solid Quality Mentors >>> >>> "Jay" <spam(a)nospam.org> wrote in message >>> news:#HfRsQciKHA.1648(a)TK2MSFTNGP05.phx.gbl... >>>> SQLIOsim, which the spell checker wants to change to Solipsism :) >>>> >>>> "Jay" <spam(a)nospam.org> wrote in message >>>> news:OhTGHEciKHA.1648(a)TK2MSFTNGP05.phx.gbl... >>>>> What is the name of that disk I/O tool? >>>>> >>>> >>>> >> >>
From: Andrew J. Kelly on 1 Jan 2010 15:30 Your best option to begin with is to look at the virtual file stats to see how much physical I/O msdb is actually doing over a given time period. It will also tell you how long it is taking to read and write those I/O's and you can see if it is too long or not. I guess he really doesn't understand SAN's very well either because SAN's are notoriously slow for writing small but frequent I/O's and direct attached drives will often outperform them hands down. If you are processing lots of Service Broker messages then that can explain some of the activity. But until you look at the file stats it is hard to say if it is handling it properly or not. -- Andrew J. Kelly SQL MVP Solid Quality Mentors "Jay" <spam(a)nospam.org> wrote in message news:#iwZMWxiKHA.1648(a)TK2MSFTNGP05.phx.gbl... > Sigh, that has basically been my argument. However, the guy has stuck to > his guns that his msdb is so active that the local drives aren't enough > and that it must be on the SAN for performance reasons. > > The best I could think of was to stress a similar drive (and monitor it) > to show what off the shelf SCSI's can do on an internal controller and > that msdb activity just doesn't come close to the drive capacity. Perhaps > SQLIO, being simpler, would be better. > > His DB seems to have a very large number of databases and each of these > DB's seem to have a lot of SQL Agent jobs that fire frequently. This > combined with heavy Message Broker activity is supposedly generating log > writes, reads and I have no clue what, to produce the "heavy activity" > that requires the SAN - which is RAID 5 BTW. > > > "Andrew J. Kelly" <sqlmvpnooospam(a)shadhawk.com> wrote in message > news:upeu61uiKHA.1236(a)TK2MSFTNGP04.phx.gbl... >> Why would MSDB be that busy? If it really is you might want to see why >> because it shouldn't be under normal circumstances. SQLIOSIM simulates >> SQL IO patterns but is not really a measurement tool per say. It is more >> to hammer the array and see where it breaks. If you want to see how it >> actually performs in general reads & writes use SQLIO. >> >> -- >> >> Andrew J. Kelly SQL MVP >> Solid Quality Mentors >> >> "Jay" <spam(a)nospam.org> wrote in message >> news:OgPyrOniKHA.1536(a)TK2MSFTNGP06.phx.gbl... >>> SQLIO++ will do. >>> >>> I'm in a discussion where a guy is saying msdb is so busy, that local >>> SCSI drives don't have enough throughput and it has to be on the SAN >>> (which is RAID 5 BTW). I was suggesting to him to run SQLIOsim to see >>> what the monitors look like when the drive is hammered and to compare it >>> to what he sees in his production environment. >>> >>> Jay >>> >>> "Andrew J. Kelly" <sqlmvpnooospam(a)shadhawk.com> wrote in message >>> news:OPl$zIiiKHA.5604(a)TK2MSFTNGP04.phx.gbl... >>>> It depends on what you want to accomplish as there are several. Can you >>>> tell us what your goal is? >>>> >>>> -- >>>> >>>> Andrew J. Kelly SQL MVP >>>> Solid Quality Mentors >>>> >>>> "Jay" <spam(a)nospam.org> wrote in message >>>> news:#HfRsQciKHA.1648(a)TK2MSFTNGP05.phx.gbl... >>>>> SQLIOsim, which the spell checker wants to change to Solipsism :) >>>>> >>>>> "Jay" <spam(a)nospam.org> wrote in message >>>>> news:OhTGHEciKHA.1648(a)TK2MSFTNGP05.phx.gbl... >>>>>> What is the name of that disk I/O tool? >>>>>> >>>>> >>>>> >>> >>> > >
From: Jay on 2 Jan 2010 07:53
Do you know of a Microsoft whitepaper that talks about SAN's being slow on small & frequent writes? "Andrew J. Kelly" <sqlmvpnooospam(a)shadhawk.com> wrote in message news:ujVlsEyiKHA.5520(a)TK2MSFTNGP06.phx.gbl... > Your best option to begin with is to look at the virtual file stats to see > how much physical I/O msdb is actually doing over a given time period. It > will also tell you how long it is taking to read and write those I/O's and > you can see if it is too long or not. I guess he really doesn't understand > SAN's very well either because SAN's are notoriously slow for writing > small but frequent I/O's and direct attached drives will often outperform > them hands down. If you are processing lots of Service Broker messages > then that can explain some of the activity. But until you look at the file > stats it is hard to say if it is handling it properly or not. > > -- > > Andrew J. Kelly SQL MVP > Solid Quality Mentors > > "Jay" <spam(a)nospam.org> wrote in message > news:#iwZMWxiKHA.1648(a)TK2MSFTNGP05.phx.gbl... >> Sigh, that has basically been my argument. However, the guy has stuck to >> his guns that his msdb is so active that the local drives aren't enough >> and that it must be on the SAN for performance reasons. >> >> The best I could think of was to stress a similar drive (and monitor it) >> to show what off the shelf SCSI's can do on an internal controller and >> that msdb activity just doesn't come close to the drive capacity. Perhaps >> SQLIO, being simpler, would be better. >> >> His DB seems to have a very large number of databases and each of these >> DB's seem to have a lot of SQL Agent jobs that fire frequently. This >> combined with heavy Message Broker activity is supposedly generating log >> writes, reads and I have no clue what, to produce the "heavy activity" >> that requires the SAN - which is RAID 5 BTW. >> >> >> "Andrew J. Kelly" <sqlmvpnooospam(a)shadhawk.com> wrote in message >> news:upeu61uiKHA.1236(a)TK2MSFTNGP04.phx.gbl... >>> Why would MSDB be that busy? If it really is you might want to see why >>> because it shouldn't be under normal circumstances. SQLIOSIM simulates >>> SQL IO patterns but is not really a measurement tool per say. It is more >>> to hammer the array and see where it breaks. If you want to see how it >>> actually performs in general reads & writes use SQLIO. >>> >>> -- >>> >>> Andrew J. Kelly SQL MVP >>> Solid Quality Mentors >>> >>> "Jay" <spam(a)nospam.org> wrote in message >>> news:OgPyrOniKHA.1536(a)TK2MSFTNGP06.phx.gbl... >>>> SQLIO++ will do. >>>> >>>> I'm in a discussion where a guy is saying msdb is so busy, that local >>>> SCSI drives don't have enough throughput and it has to be on the SAN >>>> (which is RAID 5 BTW). I was suggesting to him to run SQLIOsim to see >>>> what the monitors look like when the drive is hammered and to compare >>>> it to what he sees in his production environment. >>>> >>>> Jay >>>> >>>> "Andrew J. Kelly" <sqlmvpnooospam(a)shadhawk.com> wrote in message >>>> news:OPl$zIiiKHA.5604(a)TK2MSFTNGP04.phx.gbl... >>>>> It depends on what you want to accomplish as there are several. Can >>>>> you tell us what your goal is? >>>>> >>>>> -- >>>>> >>>>> Andrew J. Kelly SQL MVP >>>>> Solid Quality Mentors >>>>> >>>>> "Jay" <spam(a)nospam.org> wrote in message >>>>> news:#HfRsQciKHA.1648(a)TK2MSFTNGP05.phx.gbl... >>>>>> SQLIOsim, which the spell checker wants to change to Solipsism :) >>>>>> >>>>>> "Jay" <spam(a)nospam.org> wrote in message >>>>>> news:OhTGHEciKHA.1648(a)TK2MSFTNGP05.phx.gbl... >>>>>>> What is the name of that disk I/O tool? >>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> |