Is t1.micro enough? Seeing random server dropouts

I just noticed http://www.couchbase.com/forums/thread/high-cpu-usage-memcached-process-...

except as I said my high CPU usage appears to be beam.smp, not memcached, which was around 10%

Any thoughts? I can contribute my logs also if it would help.

Hello,

Could you describe your configuration and application:
- Number of Buckets
- Number and size of the documentation
- Number of Design Document (Views)
- Type of usage when it failed

t1.micro is probably too small to run in production.

Feel free to upload the logs to our S3 server and drop me a MP with the location

Can you switch to a m1?

Regards

1 bucket, < 1000 documents, all < 0.5k in size, observed no usage (servers are idling) when failure occurs, repeatedly. In between failures, usage should have been no more than about 10 concurrent connections.

One question; is there a way to find out how many open client connections a server is holding? I'm running a wsgi webserver and celeryd queue and just want to make sure my connection pooling is working and not flooding the cb server with connections.

I don't have the logs any more but will start again with m1.large and see if the dropouts keep happening.

Thank you!

I'm going to say no: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts_micro_instan...
The problem is that the cpu availability varies dramatically and unpredictably (see the graphs on the above link). This is not "normal" VM behavior, and should not be used for acceptance testing of a product. Instead, use m1.small or larger.

I use a couple of t1.micro instances full-time. One is a web server; the other is an email/dns server. The load on the email server is getting a bit much for a t1.micro, due to increasing spam volumes (running spamassassin and greylistd). The DNS load is practially zero, and the average load on the web server is around 1%.

Makes sense - thanks for the info!

Might be worth putting a note to this effect in the docs :)

Darren