Florent:
We run BaseX on EC2 micro and small instances without significant issue (though AWS servers, particularly micro/small, are not known for their high performance). Have you tried on a different instance type? Not sure how heavily loaded your instance is but understand that the t2 instance type works well for servers that are not under constant pressure (they're Burstable Performance Instances). See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html. You essentially accumulate CPU "credits" while your instance is idle, which then allows your CPU to burst to 100% when the server gets hit. If you're out of credits, your CPU may be running at as low as 10% capacity.
Now you're also workign with a 2.5Gb database on a servers with 1Gb of memory, so disk access almost inevitably comes into play. I assume you have SSD EBS volume under the hood since your on t2, but you'll be swapping, and this is more likely the problem. How much Java memory do you allocate to BaseX (-Xmx)? So I would say in your case a t2.small or preferably t2.medium would be a better choice a better choice (of course more pricy).
Talking about swap, be aware also that Amazon Linux instances don't come configured with a disk swap by default, so the 1Gb in all you get. I always add a 1Gb swap file to our micro instances using: *sudo dd if=/dev/zero of=/swapfile bs=1M count=1024 * *sudo mkswap /swapfile * *sudo swapon /swapfile* which you can verify with *sudo swapon -s *or *free -k* Also add the line below to the /etc/fstab file (so it's survives through reboot) */swapfile swap swap defaults 0 *
Hope this helps *P
On 12/18/14, 2:43 PM, Florent Gallaire wrote:
database size | shared CentOS | t2.micro EC2 CoreOS 2.4 Go | 1.5 sec 160% CPU | 30 sec 3% CPU ??!! 254 Mo | 0.35 sec 35% CPU | 0.21 sec 30% CPU 224 Ko | 0.24 sec 2% CPU | 0.14 sec 3% CPU
The CPU usage on the t2.micro is not what it should be for the 2.4Go database and explain the extreme slowness of the request. But why ??
Best regards
Florent
-- FLOSS Engineer & Lawyer