15 days = Slow....

Discussion in 'Plesk 6.0 Troubleshooting and Problems' started by DigitalCrowd, Apr 2, 2004.

  1. DigitalCrowd

    DigitalCrowd Tera Poster

    Messages:
    261
    Okay... My server is a P4 2.4GHZ, and has 2GIG of ram. Running Plesk 6 and RH9.

    For some reason, starting around December of last year, my machine started slowing down around 5-7 days into its uptime. Everything would start slow down, web, webmail, etc... rebooting always fixed it for another 5-7 days. Restarting processes like apache, mysql, mail, never did much to resolve it. It would fix it for 5 minutes and sometimes up to 24 hours, then it would just hang again. Rebooting always fixed it for another 5-7 days.

    So, I added another gig of ram to bring it up to 2 GIG. The server had a noticable increase in overall perfmance of server sites that ran vbulletin... php/mysql.

    Ever since the upgrade... although the serving of web pages never seems to degrade... about the 13th day... webmail access slows down... pages load slower... but on the 15th day, it becomes unbearable. Mind you normal IMAP clients work fine, vbulletin pages fly like the wind... usage does stay steady (via uptime) at around 3.00 - 5.00... which is much higher than normal, it increases it's avg over the days.

    I don't know what to do. Any ideas?
     
  2. hardweb

    hardweb Guru

    Messages:
    3,558
    What can you say about the swap usage after these 15 days?
     
  3. DigitalCrowd

    DigitalCrowd Tera Poster

    Messages:
    261
    Since i made the original post, I have rebooted the system on the 15 day, not because I wait until then, but that is when it slows down... this is now the 5th or more times that it needed to be rebooted exactly on the 15 day.

    [root@ root]# uptime
    18:12:45 up 15 days, 3:48, 1 user, load average: 9.07, 7.82, 6.33
    [root@ root]# free
    total used free shared buffers cached
    Mem: 2060584 2024820 35764 0 6472 859984
    -/+ buffers/cache: 1158364 902220
    Swap: 1052248 96200 956048
    [root@sunnycal root]#
     
  4. DigitalCrowd

    DigitalCrowd Tera Poster

    Messages:
    261
    After reboot...

    [root@sunnycal root]# free
    total used free shared buffers cached
    Mem: 2060584 313704 1746880 0 26896 61128
    -/+ buffers/cache: 225680 1834904
    Swap: 1052248 0 1052248
    [root@sunnycal root]# uptime
    18:20:48 up 6 min, 1 user, load average: 7.07, 2.43, 0.91
    [root@sunnycal root]#

    The load avg will slow down to around 1-2 after a little bit.
     
  5. hardweb

    hardweb Guru

    Messages:
    3,558
    Do you have any processes that do not end and eat CPU?
     
  6. DigitalCrowd

    DigitalCrowd Tera Poster

    Messages:
    261
    How do I tell that?
     
  7. hardweb

    hardweb Guru

    Messages:
    3,558
    You can check the list of the processes with 'ps aux' and 'top'. You will see the CPU time consumed by every process.
     
  8. slizard1

    slizard1 Guest

    Hi,
    I'm new to this board in hope than you could help me too. your post interested me in particular. Basically I have the same issue. Latencies every 5-7days like if it was scheduled, the best I had was 15days . I have a busy server dealing 8k/hour of surfers on 1.7ghz 512meg server with RH9 Plesk/virtuozzo on 10mbps line. It seems for me too that restarting apache or the service doesn't solve my latencies problems, reboot is the only solution. I did talk to my host, and told me that I had process that weren't killed like supposed and the CPU was jumping sometimes to 15-30, loading it abnormally. He told me that one of my script was using a lot of resources which I talked to the programmer. He did make recoding on the program, was going pretty smooth til the same problem occured around the same time & day . My host told me that Plesk wasn't made for busy server. They told me to move to another server without virutal host & webappliance. But I know that a lot of WBs are dealing with those softwares without having to deal with those issues. What you were talking about process and CPU loading abnormally are my case actually. Any help would greatly be appreciated. Thanks.
     
  9. slizard1

    slizard1 Guest

    The other programs used on the server are Comus Thumb and TM3 (Traffic Manager 3). The hosting company told me that TM3 would appear to be eating a lot resources from the CPU. I am not the first one to use these programs and thousands of WB's are using the same programs without any problems with 1 million hits a day. I am not a load balancer and the programmer from TM3 looked into it and made some tweaks to optimize the program for the server. The other guy who started this post is probably not using the same programs that I'm using and he has the same problem. I had the same software with another hosting company but with Ensin and I never encountered this type of problem why would it appear with Plesk?
     
  10. DigitalCrowd

    DigitalCrowd Tera Poster

    Messages:
    261
    I seriously doubt Plesk is the issue here. I have noticed recently somtimes when httpd restarts, whether manually or via Plesk... that https (443) doesn't die off. As a result, httpd won't start again after a restart. Usually I have to go in and kill the PID using that port and normally it just takes one -9 to kill it, but sometimes, it will take multiple (each time a differnet PID) before it goes away and httpd can be restarted.

    Maybe I have something else weird going on.

    I am not running anything non-standard to a regular Plesk install and applications like apache, mysql, etc.

    As for the PS/TOP commands, I am well aware of those, just wondered what might be a hint of a process that is "hung".
     
  11. slizard1

    slizard1 Guest

    We have the same issues here....when I do service httpd restart it can say to me that it failed....I have sometime to do it twice, and the service will restart....but in my case it doesn't solve my problem, even if processes have been erased.....latencies are way higher than normal....the only way to get back to normal is by rebooting the server .
     

Share This Page