Need Help Moving or Fixing China Manufacturing Database

Hi Guys...

My site: http://sourcing-china.com keeps going down.

My hosting company says it's due to a run-away script that hogs all resources.

Can anybody fix this or can we just move this database to a different host?

My database is filled with manufacturer data from China Japan Korean and Taiwan so its BIG.

5000 registered users.

if you can help, will you email me at sourcingasia.coATgmail ??

Thanks!

  • It's probably a matter of hardware issue, you will need to upgrade to a VPS or dedicated server to handle those requests.

  • Guys... I'm using a DV server on media temple... it's a virtual dedicated. I'll check my error log now.

  • Steve,

    You rock.

    The php error log says the same thing over and over... how do I fix this?

    Also, if you have a paypal or bitcoin, i wanna buy ya dinner!

    SEE:

    ================

    [Sat Feb 07 03:58:46 2015] [warn] [client 46.102.98.116] mod_fcgid: stderr: PHP WARNING: 2015-02-07 08:58:46 (UTC): "strtotime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone." in file /var/www/vhosts/.com/manufacturer-korea.com/manufacturers/engine/lib/configuration.php (line 621), referer: http://manufacturer-korea.com/


    [Sat Feb 07 03:58:46 2015] [warn] [client 46.102.98.116] mod_fcgid: stderr: PHP Warning:  date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /var/www/vhosts/.com/manufacturer-korea.com/manufacturers/engine/lib/elgglib.php on line 1034, referer: http://manufacturer-korea.com/


    [Sat Feb 07 03:58:47 2015] [warn] [client 87.98.137.5] mod_fcgid: stderr: PHP Warning:  date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /var/www/vhosts/.com/manufacturer-korea.com/manufacturers/engine/lib/elgglib.php on line 1034, referer: http://manufacturer-korea.com/


    [Sat Feb 07 03:58:47 2015] [warn] [client 87.98.137.5] mod_fcgid: stderr: PHP WARNING: 2015-02-07 08:58:47 (UTC): "strtotime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone." in file /var/www/vhosts/.com/manufacturer-korea.com/manufacturers/engine/lib/configuration.php (line 621), referer: http://manufacturer-korea.com/

     

  • To fix the time zone issues, add this to your engine/settings.php file

    date_default_timezone_set('America/Los_Angeles'); // Change timezone here

    As for the "run-away" script, the log doesn't show any other information to debug it.

  • I would request from whoever told you its a runaway script for more details. Normally hosting providers will provide some tools to identify largest resource users by memory or CPU.

    Sometimes hosting providers mistake the page_handler script as a runaway script because it is 90% of the utilization in a basic elgg install. If the page handler is the problem, then you probably just don't have enough resources for the size of your install. That being said, elgg is pretty efficient on memory for basic functions, so I have never seen it as a big CPU hog.

    The other thing I have seen is cron. If you have alot of notification activity and are running the cron jobs locally, then they can hog some resources.

    If the hosting provider gives you nothing, then you must have some command line access. You could probably run "top" or some other tool to have a look at top resource consumers.

    Definitely need more data gathering..

  • thanks @CIM!

    @Burrado, I have 3000+ users with a lot of profile data... i dont know if thats really that big.

    The problem first occurred when my server got full from a 10 gb error log. After deleting and restarting, ELGG ran fine for 2 days... then we had to delete the new error log that was also 10gb and restart the server again. Worked fine again. 

    This is the third time. now, ELGG isnt coming back up.