× 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.



Again for the Archives: I received a private reply with these questions:

> Where do you set this "ASYNC Bring" parameter? I see that only on
> the "SAV" command for IFS *STMF objects ...?
> You say "objects" -- what kinds of objects? Documents? In the IFS?

Yes this is the only command that supports it. These are IFS Objects, hence the use of SAV. They happen to be PDFs.

> Why would the IFS perform so badly on one type of DASD vs. another?

Same reason as why anything would perform poorly. Too few disks with too few IOPS available to support the demand.

> Also, you say "a separate ASP" -- but are you talking about an
> Independent ASP? And a UDFS?

The type of ASP wouldn't matter, they both use a UDFS to store objects.

> And, how many is "a bunch" of 1.1TB drives?

10 1.1TB drives vs the system ASP which has 48 15K 300G Disks. The difference in total IOPS is dramatic.

> You say "Write once, read maybe" -- so then, would it perhaps be
> better to create a save file for each "object", and then off-load
> (FTP, or CPYF to an NFS-mount, etc.) to some kind of NAS device? As
> soon as the save file is moved "off-platform" then delete it to
> reclaim the space, and perhaps even delete the just-saved *STMF ...
> Then, iff "maybe" becomes"yes" just reverse the process, copy the
> savf back to OS/400 SLS land, and restore the *STMF, and "read" it or
> "use" it?

That is an application question. In this case the documents must be available to web users when (if) requested so they must remain on the system. The 'Read Maybe' is a simply statement that they may never be referenced, but they might.

For reference I'm always puzzled by suggestions to move data off IBM i with complicated processes that are unlikely to be well understood by future admins. IBM i has VAST storage capability and IBM sells disks of various sizes and speeds including internal and SAN storage. And it's a very reliable machine.

> Also, why would this have such a large negative impact on the whole
> system? What kind of CPU? Power6? Power7? Power8? What version of
> IBM i? Inquiring minds want to know... (for the archives....)

For the record it's a POWER8 with 6 licensed cores and nearly 1/2TB of memory. The performance impact is because the disks are on the same RAID cards as the rest of the disks in the system. The SAS cards and buses are stuck with all the queuing to these drives. This is why IBM says to not put SSDs and spinny drives on the same RAID cards for best performance. If you mix them the spinny disks cause queuing to the SSDs crippling them.


- Larry "DrFranken" Bolhuis

www.Frankeni.com
www.iDevCloud.com - Personal Development IBM i timeshare service.
www.iInTheCloud.com - Commercial IBM i Cloud Hosting.

On 8/13/2017 8:18 PM, DrFranken wrote:
For the archives.

One of my customers added a bunch of 10K 1.1TB Drives in a separate ASP to store a large number of objects that are as we say 'write once read maybe'. A large dump of files is added to the ASP one time per month so it needs to be backed up just that one time per month. Previously the documents were in the system ASP with 15K 300G Drives and async bring *YES was used for that backup. After the move the next two backups ABSOLUTELY Killed system performance. For 12 hours the 10K disks were hammered and the entire system was like sludge, almost unusable.

Changing the async bring parameter to *NO was a game changer. The backup took 36 hours but there was zero performance impact when done this way.


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.