Pools and performance

[tommy]

Have You moved any files to other pools to increase performance?

If Yes what did You move where and why?


For unix: Have You distributed any of the files over several disks?

If Yes which files and why?

[gavster]

Hi Tommy, I have recently begun moving files around the pools and will soon moving physical files across 2 disks.

The general rule for deciding which files to move has been on usage and if the file is dynamic, static or incremental

All static files (contacts, locations etc) have been moved (or left in) data pool 3, for which I have allocated 2 physical files.

I haved moved SYSBLOB out of data pool 3 into to its on pool, because this is by far the largest file , in fact it is half the size of the whole database! I still need to find a good way of purging this file.

The rest of the pools each have roughly 1 logical file and 1 or 2 physical files allocated to them, and these are the "application files" eg problem , change, incident, this may not be the best way to do it but it makes administration easier.

In regards separting across disks, I still trying to decide what would be best as I only have 4 mirrored disks so this gives me only 2 logical disks to play with, still awaiting sign off for more disks!

But I will keep you informed what I decide...

[tommy]

Would it benifit to have data and index in seperate pools?

[pcasey]

Any given query againt P4 requires a minimum of three physical read sequences:

1) Read the Index out of whatever file the index is stored in.
2) Read the associator out of the associator file.
3) Read the physical record out of wherever the data is stored.

In theory this means that you can speed your P4 performane out of you set up your Index, your Data, and your associator file all on seperate physical drives.

In practise, moving index files around takes a long time on large files and doesn't always give you a huge benefit.

Moving the associator file (scdb.asc), to a new physical drive though is very simple and generally results in a significant performance improvement, especially on MVS e.g. put it on a seperate pack from the dbx files.

Some other general performance tips:

1) Never, ever, NFS mount any part of your P4 file system. Unix system Admins love NFS because it makes their life easier and they'll try to convince you its just as fast, or faster, than a local disk array by quoting theoretical throughput numbers at you. Don't fall for it. P4, and indeed any operation which makes large numbers of essentially randomly distributed small physical reads, runs terribly over NFS.

2) Don't worry too much about your logs. Putting time and effort into moving your logs onto seperate disks sounds like a good idea, but the actual amount of disk I/O that goes into your log files is pretty minimal so I wouldn't recommend going through the work.

3) In theory, you can put each scdb.dbx file as well as the scdb.asc file on different physical drives. If you have less than ten physical drives though, you're going to have to double up. The best rule of thumb here is make sure nothing doubles up with the associator file.

Good Luck,

--- Pat

[tommy]

Thank You.

I am currently looking into how we can improve performance for our customer. They run on MVS with SC3SP3. They are now starting to get longer response times and in a few months time we shall implement a couple of interfaces to their SC. This will result in SC having to process several millions of input and output events per year.

I will ask them to move the ASC file immediately to a new disc volume.

[tommy]

The customer have not changed the distribution of files over the different pools. I have been asked to try an optimize their SC.

The customer use SM, PM, CM and ICM. PM is the biggest and they only have 10 devices defined in ICM. SM is used but not heavily. With this in mind and the fact that SC needs to handle several million events a year I am thinking about doing following:

move device from pool 8 to 3
move spool from pool 8 to 4 (they don't use print on server)
move cm3* from pool 7 to 3 or possible 4 or leave it
add pool 8 and 9 to problem
move eventin from pool 3 to 7
move eventout from pool 3 to 7

Is this a good or bad idea?

[pcasey]

I don't think what you're proposing will do any harm, but I'm not sure you'll get a significant boost in performance out of it either unless they have a different pack for each dbx file.

The biggest (and quickest) bang for your buck is usually just moving the associator file. After that, the marginal gain gets a lot lower on the kind of changes you suggested.

[tommy]

Ok, I forgot to say that another reason for changing the pools is to make room for a higher volume of problems.

We are also recommending the customer to do a binary upgrade to SC5 to utilize more files, but above is just a short term solution.

[danstenzel]

We just had a problem where we ran out of room on our P4 database. Basically because we have everything in one pool (aka file). Our initial consultant never recommended moving any of the tables into different pools. Our main use is as an incident management system (probsummary - problem); and our HP contact recommended moving the problem table into its own pool. When we asked about putting the index in a different pool she STRONGLY advised against it inferring that we would take a performance hit.

Adding an extension (a new db file) is relatively cheap - and you take no performance hit until you actually have data in the extension file. Our HP contact also said that there is no performance hit when adding records, only when retrieving them.

I am interested in knowing if there is a performance hit/upgrade or whatever in moving a table into it's own pool (e.g. moving probsummary into its own pool even though it isn't all that big). I am also considering the possibility of moving a couple of the IM files into one pool (e.g. probsummary, activity, clocks). What have other shops done, and have you noticed any improvements, degradations, ????

Thanks - Dan

[tommy]

I would move high volume tables to a pool of their own. Pretty much as described in post #6

I would also move high activity tables to a pool of their own.

[MarMin]

Do you got any results?

[tommy]

Do you got any results?

Who are you asking? This is an 8 year old thread. Please create a new thread describing your issue.