8 Krypton

Symm Cache page size

Jump to solution
I am on DMX-3 trying to find the default cache page size for optimum performance(Windows 2003 with SQL servers)

I couldn;t locate the info from symcfg? Is there any command to find the cache page size?
Tags (2)
0 Kudos
1 Solution

Accepted Solutions
8 Krypton

Re: Symm Cache page size

Jump to solution
Here is one more question for the cache.If i am understading correctly,the smallest amount of area cache divided is by 64k.If any host writes less than 64k(assume 8k),It will wait for 8 transactions(to fill the track) before it gets destaged to disk(depending on algorthims).


No. It could happen that only 90 sectors of the possible 128 are filled before a destage will happen. It could also be that only 1 sector is written, It could also happen that 5 sectors are rewritten 10 times each and the cache slot is destaged at that point. There's no way telling when a destage will happen uinder normal circomstances.

One more on the disk:Since each track is of 64k then it will have 8 sectors/track for DMX-3 and above and then it will have 512 blocks in each sector(16 blocks per sector).Is this correct?


Each track / cache slot is 64kB, so 128 sectors of 512 bytes each.
0 Kudos
9 Replies
8 Krypton

Re: Symm Cache page size

Jump to solution
DMX3 uses 64Kb tracks.
0 Kudos
8 Krypton

Re: Symm Cache page size

Jump to solution
If this 64kb,how DMX going to address the databases blocks -Sybase(2k),Exchange(4k),SQL(8k) and oracle(16k).Does it give better performace in clariion if set to particular block size per cache page compare to DMX?

Or is this block size,when used for raw file systems(no volume management layer).In this case how can we acheive better performace?

If the Volume manager is present,Windows(32k) and unix(64k) going to mask all the writes?What's about the reads?Still DB needs,for example sybase still nees 2k..how does DMX address this need?

Is there any parameter in DMX to set this behaviour per OS/per Database?I am thinking of cache partitioning per DB..is that a better option?Any drawbacks of doing this?
0 Kudos
8 Krypton

Re: Symm Cache page size

Jump to solution
A lot of questions .. A lot of good questions .. :D

1) 64K is the size of a track. The backend reads/writes always full tracks. Thus the dialogue between the cache and the disks happens at 64K blocks.

2) you mentioned a lot of different applications/operating systems/variables that affectdialogue between the host and the frontend. But remember you always have the cache in between.

3) DMX offers SCSI disks to the hosts.

4) When an host wants to write/read something, it have to specify both the starting block and the size of the operation. The DMX will find how many tracks are needed. If the IO operation is smaller then 64K, each operation will touch at most 2 different tracks. If the IO operation is bigger it may need more tracks.

5) Let's dig what happens when the host wants to READ from the DMX. As soon as the Frontend receives the IO from the host, it will search required tracks in cache. In case one or more tracks aren't yet in cache, the frontend will ask needed tracks to the backend. As soon as the tracks are in cache, the I/O is fulfilled and the answer (the data) is returned to the host.

6) What happens when the host wants to WRITE to the DMX?? If the tracks being written are already in cache, the FA processors will put data in cache. If tracks aren't yet in cache, FA will search for available slots and put data in available cache. If there is no available cache slot the FA will ask DA to destage something and as soon as there is an empty cache slot the FA will write data in cache. As soon as all written data is in cache, the FA returns an ACK to the host.

It's easy to note that block size and alignment can affect the DMX (bad alignment and/or small random IO ops will put more pressure on the backend). It's also easy to note that io size will affect host-FA performances.

AFAIK there is no parameter you can tune in the DMX per OS or per DB. DCP may help in having predictable performances in MC environments.. But I don't think to DCP as a "parameter" :D
Highlighted
8 Krypton

Re: Symm Cache page size

Jump to solution
Stefano,

1) Disk IO in the Symm does NOT only happen with whole tracks. The minimum IO size to the backend is a 512 byte block. However for user data, we need to perform IO at the sector level which is 8k in DMX3 and above. So if the user wrote only one 512 byte block, when we destage it, we need to read the other blocks in the sector first, then we can merge the new data into that sector, and write the 8k to the disk.

4) A 512 byte IO will never occupy more than one track.

6) The front-end won't ask the DA to destage something, it will simply wait until there is a slot available.

And back to my response to #1, you can see that it can be helpful not to do partial sector writes.
8 Krypton

Re: Symm Cache page size

Jump to solution
4) that's why I said "at most" :D

I love to receive corrections !! :-)
0 Kudos
8 Krypton

Re: Symm Cache page size

Jump to solution
Thanks Stefano and Quincy.

Here is one more question for the cache.If i am understading correctly,the smallest amount of area cache divided is by 64k.If any host writes less than 64k(assume 8k),It will wait for 8 transactions(to fill the track) before it gets destaged to disk(depending on algorthims).

Is there any document that explains how the cache is divides in to different region?and is there command in DMX to see cache utilization?

One more on the disk:Since each track is of 64k then it will have 8 sectors/track for DMX-3 and above and then it will have 512 blocks in each sector(16 blocks per sector).Is this correct?
0 Kudos
8 Krypton

Re: Symm Cache page size

Jump to solution
Stefano,

1) Disk IO in the Symm does NOT only happen with
whole tracks. The minimum IO size to the backend is
a 512 byte block. However for user data, we need to
perform IO at the sector level which is 8k in DMX3
and above. So if the user wrote only one 512 byte
block, when we destage it, we need to read the other
blocks in the sector first, then we can merge the new
data into that sector, and write the 8k to the disk.



Maybe I'm reading more into it than I should be (guessing that the OS and DMX cache should normally coalesce those writes into a single larger sequential write provided they are not random), but would it be beneficial to create a filesystems with a blocksize of 8k if possible, so that I don't have to do a read + write for writes; thereby forcing host level writes to always come in at 8k to the DMX?

You would probably only apply this method on well known filesystems where files are generally >8k but have small write I/O systems; as there would be a space detriment to filesystems with large numbers of files <8k since you would have a bunch left in sloack; but if I'm thinking correctly could doing this give rather significant backend disk benefits? I could be completely off base here so correct me if I'm wrong.
0 Kudos
8 Krypton

Re: Symm Cache page size

Jump to solution
The DA won't wait for a track to be filled before destaging, however as long as there is not a rush to destage (cache filled with writes), the DA can let the slots age before destage, which can allow re-writes to the same track or data (avoiding a destage operation altogether) and also allowing adjacent blocks to be written, allowing coalescing of data, also saving IOs on the backend.
0 Kudos
8 Krypton

Re: Symm Cache page size

Jump to solution
Here is one more question for the cache.If i am understading correctly,the smallest amount of area cache divided is by 64k.If any host writes less than 64k(assume 8k),It will wait for 8 transactions(to fill the track) before it gets destaged to disk(depending on algorthims).


No. It could happen that only 90 sectors of the possible 128 are filled before a destage will happen. It could also be that only 1 sector is written, It could also happen that 5 sectors are rewritten 10 times each and the cache slot is destaged at that point. There's no way telling when a destage will happen uinder normal circomstances.

One more on the disk:Since each track is of 64k then it will have 8 sectors/track for DMX-3 and above and then it will have 512 blocks in each sector(16 blocks per sector).Is this correct?


Each track / cache slot is 64kB, so 128 sectors of 512 bytes each.
0 Kudos