This post is more than 5 years old
15 Posts
0
1562
Symstat WP question - SYMCLI Version V6.2.1.0
Good morning all.
This is my first question on the forum, so be gentle with me
I don't have a support problem to solve, I'm just using symstat to gather some info & then trying to make sure I understand the results.
What I have is a DMX-3 1500 & the volume I'm looking at is a a 5GB volume (0278) which is a Windows 2K3 boot lun.
This server has just been deployed so the Windows guys are no doubt copying zip files around & installing software etc so I thought I'd run symstat to see how it looked. I've pasted the symstat output at the end of this post.
Now here's the bit where I need you guys to check my logic if you don't mind ?
The highest number of write pending tracks in the output is at 10:14:58 where it hits 2036 in the WP column.
Given that it's a DMX-3 the track size is 64KB I think that at 10:14:58 this device had
130304KB WP data in cache which I calculated like this :-
2036 x 64 = 130304KB
Or around 127.25MB
130304 / 1024 = 127.25MB
I also have in the back of my mind that I've read that a volume in the DMX has 4% of its size assigned in cache for WP which if correct means that my 5GB volume has around 200MB ringfenced in cache, after which writes may be held while data is flushed to disk.
It would be great if someone had a second to sense check my logic here & give me any insight as to whether I'm on target with my reasoning ?
# symstat -dev 0278 -i 5
DEVICE IO/sec KB/sec % Hits %Seq Num WP
10:14:05 READ WRITE READ WRITE RD WRT READ Tracks
10:14:10 0278 (Not Visible ) 72 184 845 1367 75 100 0 732
10:14:16 0278 (Not Visible ) 31 224 328 2120 81 100 0 1020
10:14:21 0278 (Not Visible ) 14 74 275 728 50 100 0 1136
10:14:26 0278 (Not Visible ) 28 86 493 673 68 100 0 1190
10:14:32 0278 (Not Visible ) 1 23 16 271 0 100 0 1188
10:14:37 0278 (Not Visible ) 1 11 23 89 0 100 0 1096
10:14:42 0278 (Not Visible ) 22 310 346 1827 73 100 0 1084
10:14:48 0278 (Not Visible ) 4 72 127 2685 100 100 0 1408
10:14:53 0278 (Not Visible ) 30 148 510 3100 63 100 0 1814
10:14:58 0278 (Not Visible ) 78 139 584 1885 78 100 0 2036
10:15:04 0278 (Not Visible ) 7 30 112 318 57 100 0 1964
10:15:09 0278 (Not Visible ) 3 73 57 460 33 100 0 1728
10:15:15 0278 (Not Visible ) 54 35 1374 320 31 100 2 1268
10:15:20 0278 (Not Visible ) 0 12 0 76 N/A 100 N/A 1248
Thanks
Ben
This is my first question on the forum, so be gentle with me
I don't have a support problem to solve, I'm just using symstat to gather some info & then trying to make sure I understand the results.
What I have is a DMX-3 1500 & the volume I'm looking at is a a 5GB volume (0278) which is a Windows 2K3 boot lun.
This server has just been deployed so the Windows guys are no doubt copying zip files around & installing software etc so I thought I'd run symstat to see how it looked. I've pasted the symstat output at the end of this post.
Now here's the bit where I need you guys to check my logic if you don't mind ?
The highest number of write pending tracks in the output is at 10:14:58 where it hits 2036 in the WP column.
Given that it's a DMX-3 the track size is 64KB I think that at 10:14:58 this device had
130304KB WP data in cache which I calculated like this :-
2036 x 64 = 130304KB
Or around 127.25MB
130304 / 1024 = 127.25MB
I also have in the back of my mind that I've read that a volume in the DMX has 4% of its size assigned in cache for WP which if correct means that my 5GB volume has around 200MB ringfenced in cache, after which writes may be held while data is flushed to disk.
It would be great if someone had a second to sense check my logic here & give me any insight as to whether I'm on target with my reasoning ?
# symstat -dev 0278 -i 5
DEVICE IO/sec KB/sec % Hits %Seq Num WP
10:14:05 READ WRITE READ WRITE RD WRT READ Tracks
10:14:10 0278 (Not Visible ) 72 184 845 1367 75 100 0 732
10:14:16 0278 (Not Visible ) 31 224 328 2120 81 100 0 1020
10:14:21 0278 (Not Visible ) 14 74 275 728 50 100 0 1136
10:14:26 0278 (Not Visible ) 28 86 493 673 68 100 0 1190
10:14:32 0278 (Not Visible ) 1 23 16 271 0 100 0 1188
10:14:37 0278 (Not Visible ) 1 11 23 89 0 100 0 1096
10:14:42 0278 (Not Visible ) 22 310 346 1827 73 100 0 1084
10:14:48 0278 (Not Visible ) 4 72 127 2685 100 100 0 1408
10:14:53 0278 (Not Visible ) 30 148 510 3100 63 100 0 1814
10:14:58 0278 (Not Visible ) 78 139 584 1885 78 100 0 2036
10:15:04 0278 (Not Visible ) 7 30 112 318 57 100 0 1964
10:15:09 0278 (Not Visible ) 3 73 57 460 33 100 0 1728
10:15:15 0278 (Not Visible ) 54 35 1374 320 31 100 2 1268
10:15:20 0278 (Not Visible ) 0 12 0 76 N/A 100 N/A 1248
Thanks
Ben
xe2sdc
2 Intern
2 Intern
•
2.8K Posts
0
February 14th, 2008 02:00
This is my first question on the forum, so be gentle
with me
Hi Ben .. .. Usually we try to be gentle and polite .. Unless you forget to mark usefull replies
think that at 10:14:58 this device had
130304KB WP data in cache which I calculated like
this :-
2036 x 64 = 130304KB
I have to correct you .. even if in a gentle way It's right to assume that 1 track = 64 kb only if looking at the binfile of your beloved DMX3. But when you use symcli commands, you have another "variable" to play with .. In the /var/symapi/config/options file there is an option you can enable or disable, at your taste
SYMAPI_TRACK_SIZE_32K_COMPATIBLE
Remember that by default (since the option is enabled) Solution Enabler will translate DMX3 (and DMX4) 64kb tracks into 32kb tracks. Did you notice that the WP counter is always heavenly even ??
that a volume in the DMX has 4% of its size assigned
in cache for WP which if correct means that my 5GB
volume has around 200MB ringfenced in cache, after
which writes may be held while data is flushed to
disk.
WP is only half of the equation. The 4% of reserved cache is used for both reads and writes. The box may destage tracks from cache (lowering the WP count) for a lot of different reasons (tracks still in cache after a "long" time, read misses that need space in cache) .. So it's hard to fill the reserved cache with writes. This may happen during a recover (hmm restore if you don't love Networker). I'm not 100% sure but if my memory isn't failing, every volume have 4% of its capacity always reserved in cache .. but may "gain" more tracks in cache, if needed.
Have I been gentle enough ??
Cheers !!
v760
15 Posts
0
February 14th, 2008 03:00
On checking the variable you mentioned in /var/symapi/config/options it says it is enabled :-
#SYMAPI_TRACK_SIZE_32K_COMPATIBLE = ENABLE
So, with that in mind should my calculations look like this ? :-
At 10:14:58 this device had 65152KB WP data in cache calculated as follows :-
2036 x 32 = 65152KB
Or 63.62MB
65152 / 1024 = 63.62MB
Cheers !
xe2sdc
2 Intern
2 Intern
•
2.8K Posts
0
February 14th, 2008 03:00
calculated as follows :-
2036 x 32 = 65152KB
It looks good to me
-s-
RRR
2 Intern
2 Intern
•
5.7K Posts
0
February 14th, 2008 03:00
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
February 14th, 2008 03:00
xe2sdc
2 Intern
2 Intern
•
2.8K Posts
0
February 14th, 2008 03:00
new dining room table or something.
Whooosp Rob .. I forgot to tell you that my home theatre is in perfect working conditions .. Eventually I need a 60' LCD .. can you do something for me ??
Errr.. I don't need a table .. my 300cm table is still good .. Don't need to change it soon
RRR
2 Intern
2 Intern
•
5.7K Posts
0
February 14th, 2008 03:00
xe2sdc
2 Intern
2 Intern
•
2.8K Posts
0
February 14th, 2008 03:00
v760
15 Posts
0
February 14th, 2008 04:00
If I understand correctly, the amount of write pending tracks on our DMX is directly proportionate to the amount of wooden home furnishings, home cinema equipment & people carriers/MPV's that this fine chap recieves in his bonus ?
Sounds like a good deal to me I'll tell our guys to start hammering that Sym.
Cheers
Ben
RRR
2 Intern
2 Intern
•
5.7K Posts
0
February 14th, 2008 04:00
RRR
2 Intern
2 Intern
•
5.7K Posts
0
February 14th, 2008 04:00
RRR
2 Intern
2 Intern
•
5.7K Posts
0
February 14th, 2008 04:00
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
February 14th, 2008 04:00
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
February 14th, 2008 04:00
RRR
2 Intern
2 Intern
•
5.7K Posts
0
February 14th, 2008 04:00
You are correct
We are a big happy family and sometimes you can even get some great answers on the forum