Recently I had change the way in wich spool data is saved (from DB to G) in instance parameter rspo/store_location. This because we had slow print process. (they took 20 - 30 seconds per document) We have a heavy load in this.
Recently we have an issue in wich all dialog process were stuck in report SAPLSPOX (print, I guess) and they took more than 600 seconds. We have 30 DWP and all SAP were inoperable in a moment.
Any suggestions ??
Edited by: Leon Felipe Villavicencio on Jan 20, 2009 9:10 PM
Delete the old spool logs from the system, this will fix the problem.
Whenever the program SAPLSPOX will be running there must be a job that will be calling it.
Please check if any job is in active state whenever you see this program.
This will help in ananlysing.
Is there a limit in the number of stored spool requests ?
We have a heavy load (8,000 documments by day), and all of them are saved. The standard job for delete old spool requests is running every 7 days. ¿ Should we change that and reduce the number of days for delete old spool requests ?
¿ Can the number of saved spool requests be the cause for slowdown in our system ? We had 30 WP, all of them with the program SAPLSPOX and with a time of > 600 seconds in a moment, that stop the production system preventing from access to it.
Yes, you do have a limt for Spool requests. I guess it is 32000, if you exceed this limit you will end up to getting dumps in ST22.
Why do you want to reduce the frequency of the job, running the job in the default frequency will help you to delete the old spools. This will help in reducing the numbers from exceeding the limit (32000).
Lots of spools will increase the Table size but default job keeps reorganizing the table, this might not be the direct reason for the performance problem. But as you mentioned the work process utilization will surely cause the performance problem, because if all the wp are engaged at the same time you will end up in performance problems automatically.
You can schedule majority of the prints in any of the application servers if you have in your Production environment, atleast this keeps your central Instance alive.
Me again, I have another thing, in directory /sapmnt/PRD/global/400SPOOL , where spool data is stored, each file is 800 Kb or more in size, is this a concern ?
-rw-rw---- 1 prdadm sapsys 853K Jan 28 14:04 00010000009268
-rw-rw---- 1 prdadm sapsys 904K Jan 28 14:04 00010000009269
-rw-rw---- 1 prdadm sapsys 842K Jan 28 14:04 00010000009270
-rw-rw---- 1 prdadm sapsys 878K Jan 28 14:04 00010000009271
-rw-rw---- 1 prdadm sapsys 5.1K Jan 28 14:04 00010000009272
-rw-rw---- 1 prdadm sapsys 858K Jan 28 14:04 00010000009273
-rw-rw---- 1 prdadm sapsys 866K Jan 28 14:04 00010000009274
-rw-rw---- 1 prdadm sapsys 5.2K Jan 28 14:04 00010000009275
-rw-rw---- 1 prdadm sapsys 855K Jan 28 14:04 00010000009276
-rw-rw---- 1 prdadm sapsys 853K Jan 28 14:05 00010000009278
-rw-rw---- 1 prdadm sapsys 868K Jan 28 14:05 00010000009277
-rw-rw---- 1 prdadm sapsys 855K Jan 28 14:05 00010000009279
-rw-rw---- 1 prdadm sapsys 877K Jan 28 14:05 00010000009280
-rw-rw---- 1 prdadm sapsys 878K Jan 28 14:05 00010000009281
-rw-rw---- 1 prdadm sapsys 5.2K Jan 28 14:05 00010000009282
-rw-rw---- 1 prdadm sapsys 853K Jan 28 14:05 00010000009283
-rw-rw---- 1 prdadm sapsys 853K Jan 28 14:05 00010000009284
-rw-rw---- 1 prdadm sapsys 856K Jan 28 14:05 00010000009285
-rw-rw---- 1 prdadm sapsys 855K Jan 28 14:05 00010000009286
-rw-rw---- 1 prdadm sapsys 858K Jan 28 14:05 00010000009287
-rw-rw---- 1 prdadm sapsys 828K Jan 28 14:05 00010000009288
-rw-rw---- 1 prdadm sapsys 144K Jan 28 14:05 00010000009289
If we do the math: 800 KB x 8,000 prints daily = 6 GB by day.
Is this normal ? or perhaps the programming is not very good ? (we have many Z transactions)
You have set the spool parameter rspo/store_location to option 'G', this option stores the spools in the file system. rspo/store_location with value 'db' stores the spool in database.
Reports RSPO0041 and RSPO0043 (I guess new reports already available) which checks spool consistency and delete old spool respectively can be applied to both options u2013 db or G.
Advantage of having option 'G' is: Faster access to spool data; more flexibility.
Disadvantage: Files are not protected by database backup and recovery mechanisms.
Advantage of having option 'db' is: Spool files are protected by the backup and recovery mechanisms of the database system.
Disadvantage: High load on the database and possible high database maintenance cost and of course, the consequent performance degradation.
So your option is better from the advantage point of view, but keep in mind that you have enough space in the filesytem.
Check the below link.....
I guess the amount of printing done depends upon the business.