SUMMARY: T64U read/write performance/tuning

From: <Russ_Fish_at_idx.com>
Date: Fri, 15 Apr 2005 14:54:57 -0700

Thanks to David Knight (David.Knight_at_xxxxxxxxx.xxx) and Martin Rønde
Andersen (martin.roende_at_xxxxxxxx.xxx) along with one other person whose
email I cannot find.

David suggested taking a look at disk writes across cluster nodes (I
neglected to mention we are clustered). We have not done this as yet but
will definitely do so. David also supplied a perl script that allows
read/write stats for disks included in a clustered volume, and I've long
suspected that some of our problems lie here.

Martin noted that we may well be saturating the disks no matter which node they're on, so moving a disk to the other node may not prove useful.

We also opened a ticket with HP, and after looking at our collect output, the engineer recommended changing an /etc/sysconfigtab parameter
(ssm_threshhold) from 0 to 8388608. The collective memory indicates that
this parameter was set to 0 at Oracle's suggestion. Anyway, once we
changed the parameter (no reboot required), we were able to unzip and ls
simultaneously without one process blocking the other. We are not seeing
improved performance (adding weight to Martin's contention) but the
presenting problem has been resolved.
 
----- Forwarded by Russ Fish/SEA/IDX1 on 04/15/2005 02:45 PM -----

Russ Fish/SEA/IDX1
03/28/2005 03:04 PM

To
tru64-unix-managers_at_ornl.gov
cc

Subject
T64U read/write performance/tuning





Hi all--

This may be a newbie question but I'll throw it out anyway. I saw
something odd on one of our ES45 5.1B HSG80 servers last night:

1. I began unzipping a large file (Oracle export file) in a directory,
running in the background.
2. I attempted an 'ls' of the directory where the unzip was running.
3. The ls did not return until the unzip had completed.

This caused me to wonder (a) if others have seen this, (b) under what
other circumstances it happens, and (c) there's something at the file
system or AdvFS level (e.g. sysconfigdb changes) we can do about it.

--Russ


-----------------------------------------------
IMPORTANT NOTIFICATION
-----------------------------------------------
The contents of this e-mail and its attachments are confidential and may be privileged. If you are not the intended recipient of this e-mail, please notify IDX immediately (by return e-mail to either the sender or security_at_idx.com), destroy all copies of this message along with any attachments and do not disclose, copy and/or distribute the contents. The views expressed in this message are those of the author and not necessarily those of IDX. In the absence of a prior written agreement with you authorizing commitments of IDX via e-mail, the above message shall not bind IDX, unless from a duly authorized officer of the company in a context indicating an intention to bind the company.

This e-mail and its attachments are protected by copyright and other laws. © IDX Systems Corporation 2004. All rights reserved. IDX is a registered trademark of IDX Investment Corporation.
Received on Fri Apr 15 2005 - 22:12:17 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:45 NZDT