After reading others with this question, most said to be patient.
It's been running for roughly 15 hours now and still nothing.
I've got it on the AWS EC2 Micro, which I know the ram is low but I added a 512mb swap.
Both the memory and cpu sit around 90%.
Is it safe to say that it's not going to finish or will it eventually do something? Is there anyway to log this process to see what it's doing?
Composer is supposed to finish a reasonably sized install job within seconds. It might probably need some minutes to finish if there is a really huge amount of packages to be installed (by huge I mean more than I experienced yet, i.e. probably more than 100 packages).
The process uses an unusual amount of RAM compared with other PHP scripts, i.e. hundreds of megabytes is not uncommon.
I'd advise to not run Composer on such a badly equipped machine. Adding swap space will not help in any way, it will just make the machine read and write to disk heavily, delaying the whole process by orders of magnitudes (like 100 or 1000 times slower). You should run the install step on your development machine, and then copy everything to the Amazon instance.
How long does it run on your local machine?
Related
I have installed Magento-2.2.3 in windows personal computer and after the installation it loaded first time well but after that it is not responding since an hour. Actually, I am new to Magento and anybody can tell about this problem?
Follow the below points this may help you.
enable all cache may help you. Full page cache .
MySQL 5.6 has some memory issues where a defaul config will use
about 500mb of ram, to fix set performance_schema = off in your
my.cnf and restart MySQL. Also make sure you have opcache turned on
and set to at least 64mb of ram and 10000 files cached, preferable
128mb. If you tune your config you can run on a 512mb vps but it's
tricky and you won't have enough ram for fpc on varnish and reddis
sessions. 1 gb vps with the above MySQL fix should work like a champ
out of the box on a vps.
There are lots of potential reasons why, but the most common is
around file system performance. In non-production mode especially,
we hit the disk pretty hard (lots of different files). E.g. in
developer mode we generate files on the fly (CSS etc). But without
more details (PHP version? using Vagrant? VM? Docker? OS? Memory? is
machine thrashing? etc), it is pretty hard to suggest something. Its
certainly not taking any where near that long on my laptop. Can you
provide any information about your setup? (But my first
investigation would be around I/O performance - for example using
Docker/VirtualBox with file syncing back to Windows is a dog -
because the file syncing is very slow.)
I have been playing with this a while now and I thought maybe I would ask the community.
Log::write("perf", "start" );
for($i=0;$i<100000000;$i++) {}
Log::write("perf", "finish");
As you can see its a basic log write; then a cpu bound computation for 0 to 100 million.
If I execute this program on the command line it resolves in about 2.2 seconds, and if I execute this file with hhvm it resolves in 0.326 seconds. Considerably faster!
However, when I run this same exact setup in my web instance in the middle of the application (note I use the perf log guards so I know the other's are not affecting it)... the same program section runs in a whopping 5 seconds under FCGI apache2.
For the life of me I can't figure out why it would be so slow? As a note; waiting for the JIT 20 notifications to finish does not speed up the program...
Any idea what I might be doing wrong here?
As a note, this is running on Ubuntu 16.04 on an AWS c4 instance.
So we have a site running Drupal 7.41 on apache and it crashes constantly (multiple times a week). When it crashes we just restart the VM and the page start working again until the next crash. I installed New Relic in hope that it will help pin point what are some of the reasons why the site is crashing but I'm new to Drupal and maintaining it that I'm not sure where to start.
I've went to the 'Recent logs messages' section in Drupal but that doesn't seem to help. The last has been offline for some time since the last time I restarted it and the log messages don't show anything critical... just 'Notices':
On New Relic I can see that the CPU and Memory are maxed out precisely when the site crashes which gives the impression that this might be the error. Initially the site had 1GB of RAM and that was increased to 2GB when we thought this might be the problem. However, we see that it keeps maxing out so we're not sure if there really needs to be more RAM installed to avoid these crashes or if its just Apache (httpd) that tends to use that much RAM even if its not needed?
As you can see, as I restart the server, everything seems to go back to normal.
Can anyone recommend a way to help me understand what might be the problem? Is it just that 2GB is not enough RAM? If so, how do I know how much RAM might be needed?
Thanks in advance!
UPDATE#1:
I was reading this article: http://fuseinteractive.ca/blog/drupal-performance-tuning-0 on some performing techniques on Apache specifically. The first thing they mentioned was to disable modules that you might not need in order to save memory and improve performance. Upon checking the Apache configuration directory (/etc/httpd/conf.d for CentOS) I found only a few modules enabled:
Should I disable any of those?
The second point they mentioned was to update some of Apache's Default Configuration Settings. I've set mines to these:
Timeout 30
MaxKeepAliveRequests 100
KeepAliveTimeout 5
UPDATE#2: MPM Settings Updated to these values:
StartServers 5
MinSpareServers 10
MaxSpareServers 20
ServerLimit 256
MaxClients 200
MaxRequestsPerChild 0
UPDATE#3: I increased the RAM to 4GB last night and so far the physical memory usage has been steady at ~2GB for the last 12 hours. It's a weekend so there's not much traffic to the site so let's see how this behaves in the next couple of days.
First of all, I would duplicate the environment to try several things in a non-production environment. Here are some ideas of what I would do:
Install the latest version of the Drupal core
Have a look at the contributed modules you are using. Make sure you have the latest version installed.
One by one, uninstall the contributed modules and verify whether the error keeps appearing. Try to do the same with the installed themes.
I have had some problems with cron tasks. You can use the Cron Debug module to isolate the cron tasks running from each module and try to identify the problem.
Just to discard an attack, use the Hacked! module to confirm that the code you have installed in your server matches the code of the core and contributes modules available on Internet.
There are two potential problems here:
Your traffic/complexity of your site are not match for your hardware
Your drupal core using more resources than should
Your hardware looks good for average drupal site so i would go for other option. Also in your graphic you can see that CPU is 100% used before crash which means either your site is under spam attack or some module causing the problem.
Go on admin/config/system/statistics and enable access log
Go on /admin/reports/pages and /admin/reports/visitors and check number of hits per page/user on crash time.
Go on admin/config/system/cron and disable cron to see if the problem
is on some of the cron tasks.
Also it is the best practice to use latest module releases. You can easily see that on admin/reports/updates/update (you should have update manager module enabled for this). Make sure you backup potential customization on current modules before you update them.
WampServer 2.5 starts a php-win.exe process on (re-)start.
This process uses a lot of CPU and I/O, causing slowdowns on one of my harddisks and effectively 100% use of one of my CPU cores.
I typically just kill the process manually, which doesn't seem to affect anything in any way.
But I would rather the process didn't start at all, or somehow use less CPU and I/O.
What does the php-win.exe process do and how I can change it?
php-win.exe is the php command line processor but one that does not need a dos box to run in.
It is used by WAMPServer as most of WAMPServer uses PHP to do most of its stuff.
If this initial processing is causing the problems you suggest it is odd as the startup processing done in PHP usually takes milli second.
It would suggest that something is wrong somewhere.
These WAMPServer startup processes do report errors into the PHP error log so I would suggest you look in there for some clues.
Im running lemonstand which is a php based ecommerce software on a dreamhost vps.
About once or twice a week I get an email that my vps went more than 10% over its memory allocation and it is being automatically rebooted.
How do I find the source of this memory spike? I was trying to get newrelic installed to try and hunt it down, but it apparently didnt install correctly when I did the install command via ssh and well, I just dont know where to go next with it.
Is there another application or another way to hunt down the source of my memory spike?