Please review my answer to this recent question. I believe the circumstances are identical.
Do not change your MySQL configuration at this point, as MySQL is not the problem -- it's only a symptom of the problem... which is that you appear to have a system with a small amount of memory and zero swap space.
Your server is not crashing "because" memory can't be allocated for the buffer pool. Your server is crashing... and then is unable to subsequently restart due to the unavailability of system memory. All of the memory configured for the InnoDB buffer pool is requested from the system at mysql startup.
When you see this log message...
120926 08:00:51 mysqld_safe Number of processes running now: 0
...your server has already died. If it hasn't logged anything prior to this, it's not going to log anything about the first crash. The subsequent logs are from after the automatic attempt to restart.
Check your syslog and you should find messages where the kernel went looking for processes to kill due to an extreme out-of-memory condition.
Step 1 would probably be to add some swap space and/or allocating RAM if at all possible.
If that isn't possible, you might actually consider decreasing the innodb-buffer-pool size in your configuration. (I never thought I'd actually hear myself say that). As long as your database is small and your traffic is light, you may not need a buffer pool that large... and since the InnoDB Buffer Pool memory is all allocated at startup whether it's needed or not, this would free up some of your system's memory for whatever else is demanding it. (The 75% to 80%-of-total-RAM recommendation for sizing the buffer pool is only true if the whole server is dedicated to MySQL.)
Step 2 will be to review Apache's forking model and what you might need to do differently in the configuration to prevent it from overwhelming your server. It is pretty likely that uncontrolled growth in quantity or memory requirements of the Apache child processes is starting a cascade of events, resulting in the kernel killing MySQL to try to avoid a complete crash of the entire server.
Depending on how much flexibility you have, you might even consider two separate virtual machines for Apache and MySQL.
Oracle is a SQL DBMS not a truly relational database. It implements as its logical model of data a variant of SQL. Its architecture was developed in the late 1970s along the same lines as IBM's System R which was an initial implementation of a DBMS based on the relational model using SQL as the data sub-language. This short background is necessary to understand that SQL and Oracle are not the same as relational. The relational model, as defined by Codd and further developed by researchers like Date, is a purely logical model of data where data is to be presented as relations, with a relational algebra defined to manipulate the relations, and a data integrity component to make it possible for the DBMS to maintain data consistent with its real world intent. The relational model is mute on implementation by the DBMS. Therefore, when identifying a use-case that a given SQL DBMS does not handle well purely due to performance reasons, the issue lies with the implementation, not the relational model.
Given this, I suspect NoSQL solutions are sometimes recommended over SQL DBMS' for time series analysis as time series analysis is a very narrow use case and the SQL DBMS architecture was aimed at more generalized online transaction processing use cases. I know little about time series analysis but do recognize that it is purely analytical and not OLTP, and so transaction support - which is a mainstay of SQL DBMS' but orthogonal to the relational model - is pure overhead in such a use case. I recall seeing Michael Stonebraker a few years ago discuss time series analysis and argue the solution was to store data in arrays not rows. Since all the SQL DBMS's are row-stores, that may be another reason why other solutions are recommended.
I would caution against diving right into a NoSQL solution. These systems are much less mature than traditional DBMS'. Secondly, time series analysis I believe is pretty heavy statistics and you will likely have to add that yourself with a NoSQL solution. A mature SQL DBMS like Oracle may have some built in statistical features that are much easier to use. Third, SQL is, despite its flaws, a complete query language giving you the power to write queries of arbitrary complexity. Most NoSQL solutions require you to write programs to perform the analysis you want. Finally, and perhaps most importantly, it is likely that to get any useful information out of your time series data you need to "enrich" it with other related data. For example, I work for an electric utility and in this business just having a huge amount of time series data on how much power was used for an interval of time isn't very useful unless you can correlate it to weather, demographics, and so on. A SQL DBMS, precisely because it is a generalized data management solution, makes that easy. You can place the time series data in the same database as the enriching data and have the full power of SQL to join and analyze it. With a NoSQL solution you will have to perform the enrichment yourself as an additional step - potentially extracting, transforming, and loading the data from the very SQL DBMS that wasn't used to store the time series data in the first place! It will be a lot of extra work to write the ETL programs, and you have to decide at the time you write them what data will be useful for analysis. If later you decide you didn't have everything useful, you now have to write more programs. If instead you placed the time series data in Oracle right along with all your other data it is already in place and ready for analysis once you discover a need.
Bottom line I would say that unless can prove you have so much data coming in so fast as to exceed the capacity of your existing SQL DBMS installation, and you have the time and the skill sets necessary to write the additional infrastructure on top of a NoSQL solution (assuming of course the NoSQL solution you choose does have the capability to scale to the data volume and velocity), you are better off sticking with the SQL DBMS.
Best Answer
I find it interesting that Percona says that HandlerSocket is not that popular. In fact, it has bugs when writing operations interferes with open HANDLER structures.
What I also find appalling is that the concept of the HandlerSocket (known back then as HANDLER goes way back to MySQL 4.0.3 for both MyISAM and InnoDB. There were only provisions for reading at that time.
The basic usage of HANDLER is also in the book MySQL Reference Manual : Documentation From the Source, Section 6.4.2 Pages 512,513 (I have the book right here next to me)
Question remains : What purpose does the HandlerSocket serve ???
Imagine Facebook engineers trying to read a value in a MyISAM table (Facebook hates MyISAM, BTW) that is heavily trafficked. We all know that MyISAM performs a full table lock for any DML or SELECT performed. What you wanted to do is adjust a single column in a specfic row in that table (via SQL) but you need to know that data right now before SELECT queries lock it down. Do you want to wade through the humongous number of DB Connections hitting the one table you need just to change a single value? You could bypass these waiting SELECTs with no locking using the HANDLER syntax. You can do the same to InnoDB tables and bypass MVCC (MultiVersioning Concurrecy Control) and row-level locks as well.
Only in a high-traffic, high-read environment would you need to takes such a risk, especially if finding out data RIGHT NOW was the highest priority.
If you really want to know what production environments actually use it, I would write Percona directly in the blogs begging for that answer. Since I have never seen coding examples with the HANDLER (today HandlerSocket) do things other than reading, it would only serve the purposes of big MySQL installations like Facebook.
CAVEAT
When you look at the syntax for opening tables, opening indexes and traversing rows, it resembles some programming languages I coded in back in the late 1980's.
I am referring to the languages DBase, Clipper, FoxPro and Visual FoxPro. DBase was the grandfather of all these products. Now, before you start laughing and falling out of your chair, DBASE STILL EXISTS AND SO DOES VISUAL FOXPRO !!! I personally know one person that still codes in FoxPro and Visual FoxPro !!! OK, now you can fall out of your chair, crying in the fetal position. Still don't believe me ??? How about some sample code ???
Enough ranting on old data handling programming languages that resembles hierglyphics !!!