5 Replies Latest reply: Jan 28, 2009 9:51 PM by Yoganand Vedagiri RSS

Help with slow performance on server (print problems)

Currently Being Moderated

Hi,

 

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 ??

 

Thanks

 

Edited by: Leon Felipe Villavicencio on Jan 20, 2009 9:10 PM

  • Re: Help with slow performance on server (print problems)
    Yoganand Vedagiri
    Currently Being Moderated

    Hai,

     

    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.

     

     

    Regards,

    Yoganand.V

    • Re: Help with slow performance on server (print problems)
      Currently Being Moderated

      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.

       

      thanks

       

      • Re: Help with slow performance on server (print problems)
        Yoganand Vedagiri
        Currently Being Moderated

        Hai,

         

        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.

         

         

        Regards,

        Yoganand.V

        • Re: Help with slow performance on server (print problems)
          Currently Being Moderated

          HI,

           

          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)

           

          Thanks

          • Re: Help with slow performance on server (print problems)
            Yoganand Vedagiri
            Currently Being Moderated

            Hai,

             

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

            http://help.sap.com/saphelp_nw70/helpdata/en/d9/4a98ba51ea11d189570000e829fbbd/frameset.htm

            I guess the amount of printing done depends upon the business.

             

             

            Regards,

            Yoganand.V

Actions