This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi, We have been looking at the SERVER.LOG files in an effort to optimize our McIDAS servers. I got some old programs to read out its contents. -chkdde.c dde.c servacct.h- Inside servacct.h, CPU times come as: long int cpu; /* 100 X cpu seconds */ When I add up all McIDAS transactions on a busy server I get values round 1000 ~ 2000 secs per day (15 ~ 30 minutes) I never compared before these kind of figures. Any of you ever played around adding up CPU secs for a McIDAS server? In that case, what value ranges should I use to evaluate performance? To the LDM forum: Any experience on getting results for ADDE similar to what rtstats gives for LDM? Pepo +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ Jose Juega Instituto Nacional de Meteorologia Tecnico de Sistemas Leonardo Prieto Castro,8 Area de Telematica JJJJJJJ JJJJJJJ E-20071 Madrid I.N.M.-Madrid-SPAIN JJJ JJJ Ciudad Universitaria UAM (McIDAS) JJJ JJJ Tel : +34 91 581-9654 ------------ JJJ JJJ JJJ JJJ FAX : +34 91 544-5307 ____________ JJJJJ JJJJJ e-mail: address@hidden +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ Visit http://www.geocities.com/pepoj ############################################################# This message is sent to you because you are subscribed to the mailing list <address@hidden>. To unsubscribe, E-mail to: <address@hidden> To switch to the DIGEST mode, E-mail to <address@hidden> To switch to the INDEX mode, E-mail to <address@hidden> Send administrative queries to <address@hidden> Return-Path: address@hidden Received: from ssec.wisc.edu (mahogany.ssec.wisc.edu [128.104.110.2]) by unidata.ucar.edu (UCAR/Unidata) with ESMTP id j24CBsv2019741; Fri, 4 Mar 2005 05:11:54 -0700 (MST) Organization: UCAR/Unidata Keywords: 200503041211.j24CBsv2019741 X-ListServer: CommuniGate Pro LIST 4.2.9 List-Unsubscribe: <mailto:address@hidden> List-ID: <mcidas-users.ssec.wisc.edu> List-Archive: <https://ssec.wisc.edu:443/Lists/mcidas-users/List.html> Message-ID: <address@hidden> Reply-To: "McIDAS Users list" <address@hidden> Sender: "McIDAS Users list" <address@hidden> To: "McIDAS Users list" <address@hidden> Precedence: list Date: Fri, 4 Mar 2005 06:11:46 -0600 (CST) From: "John Benson" <address@hidden> X-Original-Message-ID: <address@hidden> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: ADDE performance CPU used to be very important because it was often the limiting resource. In today's systems, the balance has changed so much that most bottlenecks are elsewhere: memory, disk, comm. 30 minutes of CPU a day (out of 1440) is about 2%, far from a sign of danger. Of course, requests for meterological data are usually peaky, so the short term load could be much greater. Does vmstat or top indicate CPU saturation? If so, is it due to server activity, or something else? Look for disk busy. Look for paging. Look for network congestion. The logs will show you elapsed time as well as CPU time. The ratio between them indicates the extent to which processor time is effecting the total transaction time. Fluctuations in this ratio indicate how much you're being affected by other factors. While it's sensible to use the logs as a tuning tool, that isn't the reason they were implemented. It was for billing. And current billing implementations care more about total bytes transferred than they do about CPU. --johnb ############################################################# This message is sent to you because you are subscribed to the mailing list <address@hidden>. To unsubscribe, E-mail to: <address@hidden> To switch to the DIGEST mode, E-mail to <address@hidden> To switch to the INDEX mode, E-mail to <address@hidden> Send administrative queries to <address@hidden>