Metadata work, mostly - directory crawls, access checks, things like that (in CIFS). In NFS, ACCESS, READDIR, READDIR+ , stuff like that.
I think you can use 'cifs top -s ops' to see the busiest clients hitting the system. If the ones at the top have very high ops, but not many reads/writes, those could be your guys.
That said, it's all about latency. If it isn't driving latency higher, shouldn't be a concern. Those are different stats commands, though, can't remember right now......
--- On Fri, 6/5/09, Page, Jeremy jeremy.page@gilbarco.com wrote:
From: Page, Jeremy jeremy.page@gilbarco.com Subject: Other OPS? To: toasters@mathworks.com Date: Friday, June 5, 2009, 3:10 PM
What causes other ops? I understand that pretty much everything that hits the filer requires something but I am seeing what looks like a very high number of other ops when I do a stats show. Does this indicate a problem or is it just a busy box? It’s a mixed mode volume. Just trying to figure out what’s causing it to work so hard.
Instance total_ops read_ops write_ops other_ops nfs_read_ops nfs_write_op nfs_other_op cifs_read_op cifs_write_o cifs_other_o
/s /s /s /s /s /s /s /s /s /s
shares 1633 984 139 509 0 1 34 984 137 473
shares 2085 1173 257 654 0 2 18 1173 255 634
shares 2593 1483 253 856 0 2 221 1483 251 634
shares 3268 2306 170 791 0 1 222 2305 168 569
Please be advised that this email may contain confidential information.
If you are not the intended recipient, please do not read, copy or
re-transmit this email. If you have received this email in error,
please notify us by email by replying to the sender and by telephone
(call us collect at +1 202-828-0850) and delete this message and any
attachments. Thank you in advance for your cooperation and assistance.
In addition, Danaher and its subsidiaries disclaim that the content of
this email constitutes an offer to enter into, or the acceptance of,
any
contract or agreement or any amendment thereto; provided that the
foregoing disclaimer does not invalidate the binding effect of any
digital or other electronic reproduction of a manual signature that is
included in any attachment to this email.
So, I'm comparing the /etc/messages lines that report ops:
Fri Oct 2 03:00:00 EDT [XXXXXX: kern.uptime.filer:info]: 3:00am up 38 days, 19:46 4097331567 NFS ops, 121286775552 CIFS ops, 60 HTTP ops, 0 FCP ops, 0 iSCSI ops
with the output of qtree stats:
Volume Tree NFS ops CIFS ops -------- -------- ------- -------- vol1 qtree1 261704 212370168
Volume Tree NFS ops CIFS ops -------- -------- ------- -------- vol2 qtree2 372425752 37601 vol2 qtree3 26190085 56
I'm collecting the output of `qtree stats` every hour on the hour, to match up with the data output in the messages file.
Diff'ing the data on an hourly basis shows that the qtree stats are accounting for about 2/3'rds of the ops on the toaster. Said another way, the data output in the messages file is about 50% higher than the qtree stats.
I've checked and double-checked that there is no data, except for /etc, that is not in a qtree. No volumes have been onlined/offlined in the time interval and the filer hasn't been rebooted nor have the qtree stats been zero'ed.
So...why the discrepancy? Does qtree stats not count the same ops as the line in the messages file?
Until next time...
The MathWorks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill@mathworks.com http://www.mathworks.com ---