Results 1 to 9 of 9
  1. #1
    Join Date
    Sep 2012
    Posts
    177

    Unanswered: High CPU utilization in db2sysc.

    Hi All,

    In our setup "DB2 v9.7.0.1" and Fix Pack "1".

    Linux XXXXXXXXXX 2.6.18-400.1.1.el5 #1 SMP Sun Dec 14 06:01:17 EST 2014 x86_64 x86_64 x86_64 GNU/Linux


    Instance(db2usrin) contains only one database.

    Issue in %cpu utilization of db2sysc command. Whenever the user tried to login to Portal (Websphere) CPU utilization is going high & suddenly it's going down.

    Portal server has been restarted but still CPU utilization at the same. Any restart is required at Instance level?

    CPU utilizations:-

    [db2usrin@XXXX ~]$ top
    top - 15:02:24 up 28 days, 16:47, 2 users, load average: 0.70, 0.55, 0.52
    Tasks: 208 total, 1 running, 207 sleeping, 0 stopped, 0 zombie
    Cpu(s): 31.7%us, 3.4%sy, 0.0%ni, 63.9%id, 0.7%wa, 0.1%hi, 0.3%si, 0.0%st
    Mem: 16435984k total, 11912104k used, 4523880k free, 1740900k buffers
    Swap: 16771808k total, 2027472k used, 14744336k free, 6228080k cached

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    9982 db2usrin 21 0 2920m 726m 623m S 174.8 4.5 10221:42 db2sysc



    [db2usrin@XXXX ~]$ top
    top - 15:07:36 up 28 days, 16:52, 2 users, load average: 0.56, 0.47, 0.48
    Tasks: 208 total, 1 running, 207 sleeping, 0 stopped, 0 zombie
    Cpu(s): 14.4%us, 2.0%sy, 0.0%ni, 83.0%id, 0.6%wa, 0.0%hi, 0.1%si, 0.0%st
    Mem: 16435984k total, 11908776k used, 4527208k free, 1740912k buffers
    Swap: 16771808k total, 2027472k used, 14744336k free, 6227280k cached

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    9982 db2usrin 21 0 2920m 726m 623m S 82.1 4.5 10222:49 db2sysc


    Could you please let me know what could be the issue?

    Thanks,
    laxman.

  2. #2
    Join Date
    Apr 2012
    Posts
    1,035
    Provided Answers: 18
    Are you sure you *really* have a problem ? (a CPU spike to 31.7% is hardly interesting).
    If you are certain there is a real issue, get an experienced DBA to take a look, or if the symptom reproduces on dev/test environments you can take a look at db2top and db2pd and various other methods provided by DB2 to monitor and snapshot what's happening under the covers.

  3. #3
    Join Date
    May 2010
    Location
    India
    Posts
    84
    Provided Answers: 2
    Do you activate database using activate database command after starting instance? If database is not activated thru activate command, portal connections will be activating database making first connection slow. Set up script to activate database when instance/server is started.

  4. #4
    Join Date
    Dec 2007
    Location
    Richmond, VA
    Posts
    1,328
    Provided Answers: 5
    is there a poorly performing SQL statement that is executed at the beginning of the portal startup?
    Dave

  5. #5
    Join Date
    Sep 2012
    Posts
    177
    Quote Originally Posted by dav1mo View Post
    is there a poorly performing SQL statement that is executed at the beginning of the portal startup?

    Hi Dav/striuvee,

    Thanks for your reply.

    Instance restart not yet done it's need instance restart?? And I have checked currently database is in active state

    Active Databases

    Database name = XXXXXX
    Applications connected currently = 31
    Database path = /db/instances/db2usrin/db2usrin/NODE0000/SQL00001/


    No sql query is running. Portal user hits with their server using the corresponding user IDs. In the backend its connecting to **** db using ****instance.

    Thanks,
    laxman.

  6. #6
    Join Date
    Dec 2007
    Location
    Richmond, VA
    Posts
    1,328
    Provided Answers: 5
    laxman,
    you haven't even told us enough to know if you even have a problem.
    No sql query is running. Portal user hits with their server using the corresponding user ID’s. In the backend it’s connecting to **** db using ****instance.
    If that statement is true, then why do you have a DB? As you were already told a CPU spike of 31% is nothing, most of us wouldn't even look at that.
    Dave

  7. #7
    Join Date
    Sep 2012
    Posts
    177
    Quote Originally Posted by dav1mo View Post
    laxman,
    you haven't even told us enough to know if you even have a problem. If that statement is true, then why do you have a DB? As you were already told a CPU spike of 31% is nothing, most of us wouldn't even look at that.


    Hi Dav,

    Thanks for your reply.

    Here the issue is CPU memory utilisation when the portal team hits the Portal server. DB2 server memory utilisation is keep on increasing and decreasing.

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    9982 db2usrin 21 0 2920m 726m 623m S 174.8 4.5 10221:42 db2sysc ------ % mem is 174.8

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    9982 db2usrin 21 0 2920m 726m 623m S 82.1 4.5 10222:49 db2sysc ------- % mem is 82.1%

    Is any command is there to check what's running backend in db2sysc?

    Thanks,
    laxman.

  8. #8
    Join Date
    May 2010
    Location
    India
    Posts
    84
    Provided Answers: 2
    Laxman,

    "Database is active" does not tell you whether database is activated by activate command or by portal connections. From your output, there is no change in DB2 server memory, it is constant at 4.5% of server memory and seems low in my view. You need to work on dav1mo suggestion and check what SQL statements are running during portal startup/user login.

    Satya

  9. #9
    Join Date
    Dec 2007
    Location
    Richmond, VA
    Posts
    1,328
    Provided Answers: 5
    laxman,
    You still haven't stated an actual problem. Are your users complaining of response time issues, incorrect results, lockouts??? Previously you said CPU was spiking to 31.7%, not an issue to any of us. Now you state that memory utilization is increasing and decreasing, again a non-issue to us. Tell us exactly what problem you are having and what is happening when the issue occurs.
    Dave

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •