× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



If the virtual disk units are on a SAN then it's OK, but you really should
have at least 6 DASD units attached to the system. They can be 35GB if
needed for space. Only two drives is going to impact performance by quite a
bit so the 1 or 2 and 10 second response does not surprise me. Half a
processor is a fair bit of processor.

VIOS is on its own with one core by itself (in that environment you'd be
best off with 1 dedicated core 8 GB memory although 4GB will work) and that
can be in a different processor pool from IBM i to avoid unpleasant issues
with licensing.


--
Jim Oberholtzer
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Diego
Kesselman
Sent: Tuesday, June 20, 2017 11:37 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: QShell performance

Ok, I've checked on my own system with V7R1. This is a Power7 with just
2 virtual disks, 0.5 CPU LPAR and VIOS.

I changed my DNS to *LOCAL and a non-existing server. QSHELL performance
goes down, but just 1 second or 2 with "ls" or "hostname" commands.

Then changed my DNS to *REMOTE and the same no-existing server. QSHELL
performance goes to 10 seconds and even more with "ls" and "hostname"
commands.

I have all the hostnames entries on CFGTCP + 10 option.

Regards

Diego E. KESSELMAN


El 20/06/17 a las 10:02, Scott Klement escribió:
Diego,

What were you doing in QShell that didn't perform well when hostname
was a mess? I've seen this too, but it was under specific situations
where a program connected to the local system via Java classes.

You might think "it's the local system, why would networking even
apply" -- it applies because it's necessary to connect to network
servers to do things like call native programs, run SQL, etc. Java
(and probably other things as well) tries to determine the appropriate
IP address to connect to by asking what the local hostname is, then
doing an IP address lookup on that name. If that name isn't in the
hosts table, then it'll try a DNS server. If the DNS server is slow,
this can add a huge overhead. Likewise, if there are multiple DNS
servers and one is timing out, it can add a huge overhead. IBM has
run into this many times, so one of the first things they look for is
to make sure your local host name is in the hosts file so this doesn't
happen.

But, what Mark is doing doesn't use those network servers. He's
running native C code that directly runs on the local system.




On 6/20/2017 9:30 AM, Diego Kesselman wrote:
Skott,

I've experienced slow response in QSHELL when hostname is a mess.

Mark,

Do you have any DNS configuration ? (CFGTCP -> Option 12) If so, are
you using *LOCAL or *REMOTE ?

Do you have an entry on host tables for FQDN (hostname + domain name)
and hostname ?

Regards

Diego Kesselman


El 20/06/17 a las 09:15, Scott Klement escribió:
Mark,

I must admit, I don't see what Diego's suggestion has to do with
what you are doing... his suggestion is more related to Java
programs being able to detect and connect to the local system --
which is known to perform slowly if you don't have the local host
name in your hosts table. But, has nothing to do with your shell
script.

But, I'm really shocked at the result... 15 seconds to run
'hostname'?! Seriously? This is just a simple program that
retrieve's the system's hostname from memory and prints it.
Shouldn't even take 1 second on a slow system.

Something is very wrong.

-SK


On 6/19/2017 9:53 PM, mlazarus wrote:
Diego,

hostname took about 15 seconds. java -version took about 50
seconds.

-mark



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.