scratch space issue

Krazykoolrohit · Post by **Krazykoolrohit** » Tue Mar 14, 2006 3:55 pm

Hi,

we are constantly facing this issue of scratch space full which causes our jobs to abort. We have around 15 jobs using the same scratch space ( 4 nodes) but out of these around 4 fail everyday.

Please let me know of any posible solutions. Do i need a scratch cpace in another file system and use two configuration files. Please note having another file system is not possible at this stage.

waiting for some replies,
Rohit

ray.wurlod · Post by **ray.wurlod** » Tue Mar 14, 2006 4:02 pm

In a word, MORE.

You cannot stint for parallel jobs. If you can't get another file system, then you have no possible solution for "file system full" and you should go back to server jobs until you can get some more disk space. Parallel jobs are far more resource hungry than server jobs; the extra resources are the cost of the increased throughput benefit, which is probably why your employers bought Enterprise Edition. Given the money they spend on that, another disk or two is peanuts in comparison.

vmcburney · Post by **vmcburney** » Tue Mar 14, 2006 5:09 pm

Are those 15 jobs running concurrently or are they sequenced? You could try running just one job at a time, since this is a parallel architecture they should still run quickly.

As Ray says you shouldn't be getting anywhere close to 100% usage on those disks. Expand them or find another disk somewhere and turn it into a resource pool for a specific function such as sorting.

kumar_s · Post by **kumar_s** » Tue Mar 14, 2006 10:40 pm

Some time not all the jobs produced during run time where cleaned. If this is that serious, it may be worth cleaning the tmp directories manually (periodically).

ray.wurlod · Post by **ray.wurlod** » Wed Mar 15, 2006 5:42 am

It's always worth cleaning entries that are no longer needed from file systems. It's the fact that people don't that keeps disk vendors in business (in part at least). Pretty anything in the directories identified as scratch disk resource is a candidate (provided no jobs are running), as well as anything in the directory whose pathname is stored as UVTEMP in the uvconfig file. Ideally /tmp is not used by DataStage.