Search the Community
Showing results for tags 'digitalocean'.
-
Note - I've not set this up, I'm not experienced, I'm probably omitting much relevant information as a result so this post will be a bit of a work in progress. The answer may be on the forum here - If it is I can't tell for lack of experience (I've looked). I cannot for the life of me get an install to work and I've tried a lot, and I've asked others who're also struggling but I'll try posting here before another CMS as I've heard it's nice. Info about the server : https://gist.github.com/65086fbc7b5dd03abd0f0461b9c0ec8b I'm using the `stable` version of Processwire. My `htaccess` file is working - you can test here http://rightangle.space/ and click on the admin page to see the internal server error. Here is the htaccess file https://gist.github.com/3b805b8ab3c7978aca90a6e39773da00 Here is the /etc/apache2/apache2.conf file https://gist.github.com/2b2f2518ce7df4af4739413bc967cf56 Here is the /etc/apache2/sites-enabled/000-default.conf file https://gist.github.com/400cc958ff32dfb6df80693fd8531f08 Here's the output of tree -fa /var/www/ https://gist.github.com/a3569becd9889b4b05c4f0d0a8a561d7
-
Hello fellow PW devs! This is a short story from the server management trenches. These past couple of days trying to solve an unexpected problem: after DigitalOcean patched the droplets in NYC3 region last week, my client's droplet became almost useless and went down a couple of times. The droplet has 2GB RAM and was running Ubuntu 16.04 that was updated to kernel 4.4.0-116 after the patch. The server was provisioned using Forge (forge.laravel.com). After sshing into it, and running "top" I've noticed the cause: "php-fpm7.1" processes (3-5 instances) were spiking the CPU to 100%. This was very odd, as the CPU usually kept around 33% most of the time. The site uses ProCache and markupCache and was getting around 800-1000 visits/day last week. I checked everything on PW's side and nothing seemed out of place, so I went restarting PHP and Nginx but the problem continued. I checked access logs and no suspicious activity shown up. I upgraded PHP to 7.2 to see if anything will changed but the problem continued. My only guess after all that is that the droplet in question got screwed up somehow, because I didn't see any complaints on the web of other people getting the same problem on DO (But I confess that I did a quick Google search only). So in the end I decided to create a new droplet, now with 2 CPU cores and kept the 2GB (1 extra core and $5 cheaper ). Reinstalled PW there and pointed the floating IP to this new server. The installation went smooth but to one issue: error log started to show messages of MySQL showing "to many files" error when the users were searching. I've never encountered this message before, so after reading some StackOverflow posts, I changed mysql.services config file to remove its file limit (https://stackoverflow.com/a/36807137) Everything is normal now, but I think I'll never discover what truly happened. Anyone else had this kind of problem with MySQL before?
-
- 2
-
- digitalocean
- high cpu
-
(and 1 more)
Tagged with:
-
HELLO! I've had two Timeouts recently on a site due to the server being overloaded. The site is hosted on digitalocean on a single distro with 512 MB Memory, 20 GB disk, Ubuntu 14.04.4 x64. as shown below before each outage I can a climbing peak in user bandwidth then the CPU hangs: (the light blue above is user, and the dark blue sys) Not really had anything like this before with processwire as am puzzled. the site gets between 200 - 1000 visits a day, and I'm using the PW built in caching. Any advice or tips would help loads!
- 20 replies
-
- digitalocean
- overload
-
(and 1 more)
Tagged with:
-
Hi guys, I have replicated my local gulp workflow on a digitalocean droplet, and I can't seem to get browsersync to work. Has anybody tried this before and can chime in? My PW install is at http://clients.domain.com/clientname/ In there, my folder setup looks like this, so gulp runs from the /templates folder: clients + public + clientname + site + templates + node_modules + gulpfile.js + package.json + src/ + assets/ I tried all kinds of shenanigans including leaving out any proxy settings, setting a proxy, different port and fiddling with the scriptPath options... gulp.task('browser-sync', function(){ browserSync.init({ scriptPath: function (path, port, options) { return options.getIn(['urls', 'external']) + path; } }); }); // or this: gulp.task('browser-sync', function(){ browserSync.init({ host: 'XX.XX.XX.XX', open: 'external', proxy: 'clients.domain.com/clientname/' }); }); Gulp and browsersync is running fine it seems, only the integration is tricky: I get timeouts or 404s with the auto generated snippet (apparently the relevant files are created dynamically on runtime, but I can't access or see them at the default paths) I'm probably missing something very obvious, can't be this hard, can it? - - - EDIT: Could this simply be a firewall issue? - entering the IP @ Browsersync's default port (3000) doesn't load anything - I used serverpilot to configure the machine so the firewall is set up with very few ports open, and obviously 3000/3001 is not one of them. I guess I'm off to find out if opening one of these ports is a good idea or not - - - EDIT 2: When running netstat -peanut I can see that the relevant ports are actually listening, so this is not a firewall issue after after all? tcp6 0 0 :::3002 :::* LISTEN 1000 184931 17882/gulp tcp6 0 0 :::3003 :::* LISTEN 1000 184942 17882/gulp
- 4 replies
-
- browsersync
- gulp
-
(and 2 more)
Tagged with: