BLOG_AMAZON

RDS MySQL Connection Limits by AWS Instance Type

The RDS Connection Calculation Problem

When using Amazon Web Services’ RDS MySQL service on the back end of clusters of web servers, one resource constraint that can occur in times of heavy load is database connection starvation.

Planning capacity in the RDS MySQL layer often comes down to ensuring enough connections are available; avoiding queuing on the web tier for connection releases.

But how do you know how many connections you get from a given instance type?

The Solution

Fortunately there is a useful little calculation to determine connections by instance type:

max_connections={DBInstanceClassMemory/12582880}

That’s 12582880 bytes by the way….

So for example:

RDS Connection Limits by Instance Type

A Large RDS MySQL Instance with 7.5 GB memory has a limit of 640 connections.

You can find more out about the various RDS MySQL instance types at this page. You can feed the memory information listed there into the equation above to work out connection limits for all current RDS instance types.

 

BLOG_AMAZON

Speed your Filesystem with naotime option

Every bit of performance Push Entertainment can get out of a Magento or WordPress installation makes for a better user experience. Thats why we delve into the details…
By default, Linux records information about when files were created and last modified as well as when it was last accessed. There is a cost associated with recording the last access time.
The commonly used ext3 file system of Linux has an attribute that allows the super-user to mark individual files such that their last access time is not recorded.
So assuming you have the right level of access to your servers take a look at the File System Table:
 
more /etc/fstab</span>
#
LABEL=/     /           ext4    defaults,noatime     1   1
sysfs       /sys        sysfs   defaults             0   0
proc        /proc       proc    defaults             0   0
/dev/xvdf   /mnt/ebs    ext3    defaults             0   0
 
In the example above we can see that our EBS volume (/dev/xvdf) is still using Last Accessed Time.
 
We can alter that entry to read like this:
/dev/xvdf /mnt/ebs   ext3 defaults,noatime 0 0
Now let’s re-mount the volume so the new settings go into effect:

mount /mnt/directory -o remount


Check the current mounts to see they are effective

cat /proc/mounts
rootfs / rootfs rw 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
/dev/xvdf /mnt/ebs ext3 rw,noatime,errors=continue,user_xattr,acl,barrier=1,data=ordered 0 0

notice the new noatime setting is reflected in the output

Thats it – 30% of filesystem timestamp overhead gone!