SSD-HDD Question

My new system contains a SSD assigned as drive C: and a HDD with several
virtual drives on it.

I am going to install Win 7 on the SSD C: drive.

My question is: Should I locate the Windows pagefile "virtual memory"
cache on the SSD, or on the HDD?

I've typically used a cache size of around 2 GB in the past, and
occasionally flush it by resizing it.

The reason I ask concerns the write wearing of the SSD. I presume that
the cache gets rewritten frequently in the course of the power being on
the system, although I really don't have any direct knowledge of this.

The other consideration concerns the response time of the HDD vs the
very fast respomnce and lack of seek time of the SSD.

Any thoughts on the matter would be considered and appreciated. If
someone has actually done some testing of SSD vs HDD cache and can tell
me that the performance is not significant, or that it is very
significant, that would be a great help.

DA

On 28/09/2012 07:58, DrArm wrote:
My new system contains a SSD assigned as drive C: and a HDD with several
virtual drives on it.

I am going to install Win 7 on the SSD C: drive.

My question is: Should I locate the Windows pagefile "virtual memory"
cache on the SSD, or on the HDD?

I've typically used a cache size of around 2 GB in the past, and
occasionally flush it by resizing it.

The page file (or swap file) is a completely different concept from
"cache". So don't call it that.

Don't bother trying to manually fiddle with the cache size - unless you
have particular requirements and know what you are doing, the OS will
manage it well enough on its own. There is no such concept as "flush"
on the page file - you can flush a cache, but the pagefile is not a cache.


The reason I ask concerns the write wearing of the SSD. I presume that
the cache gets rewritten frequently in the course of the power being on
the system, although I really don't have any direct knowledge of this.


It is absolutely fine to have the pagefile on an SSD, as long as you
have a reasonable quality SSD and you have plenty of ram in the machine.
The swap file will not be used much, you will not wear out the SSD,
and you will get fast response.

It is an outdated myth that SSD's wear out. They /do/ have limited
lifetimes - but so do hard disks. And with a decent quality SSD, you
will be hard pushed to wear it out even with a few years of continuous
writing. So as long as you don't assume it will last forever, and keep
backups (just like with hard disks), you can pretty much ignore wear on
an SSD.

And as said, the page file is not a cache, and it does not get
re-written frequently - unless you are trying to use far more memory
than your system has. If that's the case, you should use fewer or
simpler programs, or buy more ram, because your machine will be very slow.

The other consideration concerns the response time of the HDD vs the
very fast respomnce and lack of seek time of the SSD.

Any thoughts on the matter would be considered and appreciated. If
someone has actually done some testing of SSD vs HDD cache and can tell
me that the performance is not significant, or that it is very
significant, that would be a great help.

DA

On 28/09/2012 1:58 AM, DrArm wrote:
My new system contains a SSD assigned as drive C: and a HDD with several
virtual drives on it.

I am going to install Win 7 on the SSD C: drive.

My question is: Should I locate the Windows pagefile "virtual memory"
cache on the SSD, or on the HDD?

I've typically used a cache size of around 2 GB in the past, and
occasionally flush it by resizing it.

The reason I ask concerns the write wearing of the SSD. I presume that
the cache gets rewritten frequently in the course of the power being on
the system, although I really don't have any direct knowledge of this.

The other consideration concerns the response time of the HDD vs the
very fast respomnce and lack of seek time of the SSD.

Any thoughts on the matter would be considered and appreciated. If
someone has actually done some testing of SSD vs HDD cache and can tell
me that the performance is not significant, or that it is very
significant, that would be a great help.

When I first upgraded my boot drive to SSD, I did make sure I moved the
pagefile off to an alternate hard drive (actually multiple alternate
drives in my case) on concerns over the wear rate on the SSD. I
eventually found that these wear-rate concerns were overblown, and
really should be meant as recommendations rather than requirements.
There are many new laptops out there which are being sold with only
SSD's in them, and no HDD's whatsoever, so obviously these systems are
expected to do all of their paging to the SSD. However, I still
recommend moving the pagefile off to another drive if possible, for
another reason which I'll get to later.

The other concern about the pagefile being slower on a HDD rather than
an SSD is also overblown. What you really should do is put the pagefile
on the least busy internal drive you have on your system. You can
determine how busy your drives are by using the Windows Resource Monitor
that came in Windows 7. Check the disks subsection and check the drives'
disk queue lengths. Any disk queue length under 1.00 is good, and the
lower the better, any disk queue higher than 1.00 is bad.

Also Windows has the ability to split up its pagefiles over multiple
drives, and it uses them in a round-robin fashion which further eases up
on disk queue lengths. I think Windows can split up its pagefiles over
upto 16 separate drives maximum (but I might be wrong about that number,
I'm going by memory). I've personally got my pagefiles distributed over
5 separate drives.

Now the reason I suggest still moving the pagefile off the SSD is
because in some cases SSD's have been known to have compatibility
problems with certain power management features of Windows. What this
results in is that you may experience random temporary freezing on your
drive, where the drive becomes 100% busy for maybe upto 10 seconds at a
time. It's an annoying behaviour if this happens on a system with its
pagefile on a different drive, but it's a critically dangerous behaviour
on systems with the pagefile on the SSD, as it results in a BSOD. If the
system can't access a certain file for 10 seconds, it's not so bad, but
it's really bad if it can't access its pagefile for 10 seconds.

I'm not saying that you'll experience these problems yourself, but if
you do, then having the pagefile safely off on an old hard drive is the
best course of action and it'll give you enough time to find a solution
to the annoying freezing problem (or just look up the solution based on
previous people's experiences).

Yousuf Khan

On Sun, 30 Sep 2012 13:37:04 -0400, Yousuf Khan wrote:

On 28/09/2012 1:58 AM, DrArm wrote:
My new system contains a SSD assigned as drive C: and a HDD with several
virtual drives on it.

I am going to install Win 7 on the SSD C: drive.

My question is: Should I locate the Windows pagefile "virtual memory"
cache on the SSD, or on the HDD?

I've typically used a cache size of around 2 GB in the past, and
occasionally flush it by resizing it.

The reason I ask concerns the write wearing of the SSD. I presume that
the cache gets rewritten frequently in the course of the power being on
the system, although I really don't have any direct knowledge of this.

The other consideration concerns the response time of the HDD vs the
very fast respomnce and lack of seek time of the SSD.

Any thoughts on the matter would be considered and appreciated. If
someone has actually done some testing of SSD vs HDD cache and can tell
me that the performance is not significant, or that it is very
significant, that would be a great help.

When I first upgraded my boot drive to SSD, I did make sure I moved the
pagefile off to an alternate hard drive (actually multiple alternate
drives in my case) on concerns over the wear rate on the SSD. I
eventually found that these wear-rate concerns were overblown, and
really should be meant as recommendations rather than requirements.
There are many new laptops out there which are being sold with only
SSD's in them, and no HDD's whatsoever, so obviously these systems are
expected to do all of their paging to the SSD. However, I still
recommend moving the pagefile off to another drive if possible, for
another reason which I'll get to later.

The other concern about the pagefile being slower on a HDD rather than
an SSD is also overblown. What you really should do is put the pagefile
on the least busy internal drive you have on your system. You can
determine how busy your drives are by using the Windows Resource Monitor
that came in Windows 7. Check the disks subsection and check the drives'
disk queue lengths. Any disk queue length under 1.00 is good, and the
lower the better, any disk queue higher than 1.00 is bad.

Also Windows has the ability to split up its pagefiles over multiple
drives, and it uses them in a round-robin fashion which further eases up
on disk queue lengths. I think Windows can split up its pagefiles over
upto 16 separate drives maximum (but I might be wrong about that number,
I'm going by memory). I've personally got my pagefiles distributed over
5 separate drives.

AFAICT windows has to be forced into using extra drives for paging.
I put the paging file into a smallish partition (80GB) near the fast
end of the drive, apart from SSD Win7 box has four drives, each
with a paging file. Overkill? Perhaps. Drives space is cheap.

Now the reason I suggest still moving the pagefile off the SSD is
because in some cases SSD's have been known to have compatibility
problems with certain power management features of Windows. What this
results in is that you may experience random temporary freezing on your
drive, where the drive becomes 100% busy for maybe upto 10 seconds at a
time. It's an annoying behaviour if this happens on a system with its
pagefile on a different drive, but it's a critically dangerous behaviour
on systems with the pagefile on the SSD, as it results in a BSOD. If the
system can't access a certain file for 10 seconds, it's not so bad, but
it's really bad if it can't access its pagefile for 10 seconds.

Aggressive power management on a laptop might be an issue. Not on a
desktop?

I'm not saying that you'll experience these problems yourself, but if
you do, then having the pagefile safely off on an old hard drive is the
best course of action and it'll give you enough time to find a solution
to the annoying freezing problem (or just look up the solution based on
previous people's experiences).

Well, not really old drives

Grant.

Yousuf Khan

On 01/10/2012 02:57, Grant wrote:
On Sun, 30 Sep 2012 13:37:04 -0400, Yousuf Khan wrote:

On 28/09/2012 1:58 AM, DrArm wrote:
My new system contains a SSD assigned as drive C: and a HDD with several
virtual drives on it.

I am going to install Win 7 on the SSD C: drive.

My question is: Should I locate the Windows pagefile "virtual memory"
cache on the SSD, or on the HDD?

I've typically used a cache size of around 2 GB in the past, and
occasionally flush it by resizing it.

The reason I ask concerns the write wearing of the SSD. I presume that
the cache gets rewritten frequently in the course of the power being on
the system, although I really don't have any direct knowledge of this.

The other consideration concerns the response time of the HDD vs the
very fast respomnce and lack of seek time of the SSD.

Any thoughts on the matter would be considered and appreciated. If
someone has actually done some testing of SSD vs HDD cache and can tell
me that the performance is not significant, or that it is very
significant, that would be a great help.

When I first upgraded my boot drive to SSD, I did make sure I moved the
pagefile off to an alternate hard drive (actually multiple alternate
drives in my case) on concerns over the wear rate on the SSD. I
eventually found that these wear-rate concerns were overblown, and
really should be meant as recommendations rather than requirements.
There are many new laptops out there which are being sold with only
SSD's in them, and no HDD's whatsoever, so obviously these systems are
expected to do all of their paging to the SSD. However, I still
recommend moving the pagefile off to another drive if possible, for
another reason which I'll get to later.

The other concern about the pagefile being slower on a HDD rather than
an SSD is also overblown. What you really should do is put the pagefile
on the least busy internal drive you have on your system. You can
determine how busy your drives are by using the Windows Resource Monitor
that came in Windows 7. Check the disks subsection and check the drives'
disk queue lengths. Any disk queue length under 1.00 is good, and the
lower the better, any disk queue higher than 1.00 is bad.

Also Windows has the ability to split up its pagefiles over multiple
drives, and it uses them in a round-robin fashion which further eases up
on disk queue lengths. I think Windows can split up its pagefiles over
upto 16 separate drives maximum (but I might be wrong about that number,
I'm going by memory). I've personally got my pagefiles distributed over
5 separate drives.

AFAICT windows has to be forced into using extra drives for paging.
I put the paging file into a smallish partition (80GB) near the fast
end of the drive, apart from SSD Win7 box has four drives, each
with a paging file. Overkill? Perhaps. Drives space is cheap.

Don't forget that if you are doing a lot of paging, paging to disks will
disrupt the normal access to that disk. So if you have occasional
situations when you need a lot of paging (perhaps you occasionally run
something need lots of memory, but don't want to buy real ram), then
spreading it around multiple disks will speed up the paging. But if you
also need to access files quickly on those disks, the paging will
interfere badly. And if you find your system is regularly doing a
little bit of access to the page file(s), but not enough to worry about
its speed, then you might get a faster system by having paging only on
the SSD (or only on the least-used hard drive).

On 30/09/2012 8:57 PM, Grant wrote:
On Sun, 30 Sep 2012 13:37:04 -0400, Yousuf wrote:
Also Windows has the ability to split up its pagefiles over multiple
drives, and it uses them in a round-robin fashion which further eases up
on disk queue lengths. I think Windows can split up its pagefiles over
upto 16 separate drives maximum (but I might be wrong about that number,
I'm going by memory). I've personally got my pagefiles distributed over
5 separate drives.

AFAICT windows has to be forced into using extra drives for paging.
I put the paging file into a smallish partition (80GB) near the fast
end of the drive, apart from SSD Win7 box has four drives, each
with a paging file. Overkill? Perhaps. Drives space is cheap.

"Forcing" Windows to use pagefiles on other drives is really not that
difficult, just a couple of extra clicks in the virtual memory setup
section. As you said, hard drive space is cheap, and it's well worth it
to move it off the SSD for that reason.

Now the reason I suggest still moving the pagefile off the SSD is
because in some cases SSD's have been known to have compatibility
problems with certain power management features of Windows. What this
results in is that you may experience random temporary freezing on your
drive, where the drive becomes 100% busy for maybe upto 10 seconds at a
time. It's an annoying behaviour if this happens on a system with its
pagefile on a different drive, but it's a critically dangerous behaviour
on systems with the pagefile on the SSD, as it results in a BSOD. If the
system can't access a certain file for 10 seconds, it's not so bad, but
it's really bad if it can't access its pagefile for 10 seconds.

Aggressive power management on a laptop might be an issue. Not on a
desktop?

Actually all of these problems occurred on a desktop of mine. The power
management is really a device power management, designed to reduce power
utilization in the peripherals like the drives.

Yousuf Khan

On 01/10/2012 2:50 AM, David Brown wrote:
Don't forget that if you are doing a lot of paging, paging to disks will
disrupt the normal access to that disk. So if you have occasional
situations when you need a lot of paging (perhaps you occasionally run
something need lots of memory, but don't want to buy real ram), then
spreading it around multiple disks will speed up the paging. But if you
also need to access files quickly on those disks, the paging will
interfere badly. And if you find your system is regularly doing a little
bit of access to the page file(s), but not enough to worry about its
speed, then you might get a faster system by having paging only on the
SSD (or only on the least-used hard drive).

Usually the busiest drive on a system is always the system disk, as not
only is the operating system accessed through that, but by default in
Windows most applications are located there too. All other disks are
secondary data disks. Just keep your eye out on the disk queue length in
the Resource Monitor and you'll see for yourself that this is the case.
Rarely are other disks as busy as the system disk. Just as long as your
keep your disk queue below 1.00 (i.e. that's the average number of
processes waiting to utilize that disk at any given instance), then it's
fine, paging and regular file access isn't really interfering with one
another.

However, when you put the paging file on the system disk, then that's
when they are really going to interfere with each other.

Yousuf Khan

On Mon, 01 Oct 2012 22:21:53 -0400, Yousuf Khan wrote:

On 30/09/2012 8:57 PM, Grant wrote:
On Sun, 30 Sep 2012 13:37:04 -0400, Yousuf wrote:
Also Windows has the ability to split up its pagefiles over multiple
drives, and it uses them in a round-robin fashion which further eases up
on disk queue lengths. I think Windows can split up its pagefiles over
upto 16 separate drives maximum (but I might be wrong about that number,
I'm going by memory). I've personally got my pagefiles distributed over
5 separate drives.

AFAICT windows has to be forced into using extra drives for paging.
I put the paging file into a smallish partition (80GB) near the fast
end of the drive, apart from SSD Win7 box has four drives, each
with a paging file. Overkill? Perhaps. Drives space is cheap.

"Forcing" Windows to use pagefiles on other drives is really not that
difficult, just a couple of extra clicks in the virtual memory setup
section. As you said, hard drive space is cheap, and it's well worth it
to move it off the SSD for that reason.

I'm not sure windows uses other drives in 'auto' mode The other
reason to 'force' paging files is to disable windows adjusting paging
file size on-the-run, perhaps not an issue these days but it used to
be quite noticeable years ago.

Anyway, I took paging files off the three working data drives and left it
on the first (80GB) partition on the much less busy (2TB) archive drive.

That should address what you and David are saying about paging location

Grant.

Now the reason I suggest still moving the pagefile off the SSD is
because in some cases SSD's have been known to have compatibility
problems with certain power management features of Windows. What this
results in is that you may experience random temporary freezing on your
drive, where the drive becomes 100% busy for maybe upto 10 seconds at a
time. It's an annoying behaviour if this happens on a system with its
pagefile on a different drive, but it's a critically dangerous behaviour
on systems with the pagefile on the SSD, as it results in a BSOD. If the
system can't access a certain file for 10 seconds, it's not so bad, but
it's really bad if it can't access its pagefile for 10 seconds.

Aggressive power management on a laptop might be an issue. Not on a
desktop?

Actually all of these problems occurred on a desktop of mine. The power
management is really a device power management, designed to reduce power
utilization in the peripherals like the drives.

Okay, I did check the power management is not shutting drives down

Yousuf Khan

"Yousuf Khan" shared his thoughts on SSDs:
[ ...... ]

Have you ever thought of using a small capacity SSD
for the pagefile?

Is it implicit in your discussion that you've maxed out
your RAM (which can be seen a fast pagefile)?

*TimDaniels*

On 02/10/2012 04:27, Yousuf Khan wrote:
On 01/10/2012 2:50 AM, David Brown wrote:
Don't forget that if you are doing a lot of paging, paging to disks will
disrupt the normal access to that disk. So if you have occasional
situations when you need a lot of paging (perhaps you occasionally run
something need lots of memory, but don't want to buy real ram), then
spreading it around multiple disks will speed up the paging. But if you
also need to access files quickly on those disks, the paging will
interfere badly. And if you find your system is regularly doing a little
bit of access to the page file(s), but not enough to worry about its
speed, then you might get a faster system by having paging only on the
SSD (or only on the least-used hard drive).

Usually the busiest drive on a system is always the system disk, as not
only is the operating system accessed through that, but by default in
Windows most applications are located there too. All other disks are
secondary data disks. Just keep your eye out on the disk queue length in
the Resource Monitor and you'll see for yourself that this is the case.
Rarely are other disks as busy as the system disk. Just as long as your
keep your disk queue below 1.00 (i.e. that's the average number of
processes waiting to utilize that disk at any given instance), then it's
fine, paging and regular file access isn't really interfering with one
another.

However, when you put the paging file on the system disk, then that's
when they are really going to interfere with each other.

Yousuf Khan

When I hear someone talking about having multiple disks (more than two)
in a system, I assume they have a lot of data. In such cases, the
system disk is not necessarily the busiest disk - other disks containing
video data, virtual machine images, data served to other computers,
etc., can easily be busier. There hasn't been any mention of server
activity, so the system disk is /probably/ the busiest - but not
necessarily.