+1 for Rob comment. I would add that I have been learning a lot from running t1.micro (then small, medium, Large, ..., i2.2XL) on AWS machines (800 MB RAM). I had to tweak every single parameter in cassandra.yaml and cassandra-env.sh. So I leaned a lot about internals, I had to! Even if I am glad I had this chance to learn, I must say production wasn't that stable (latency was not predictable, a compaction was a big event to handle...).
So, like Jack, I globally really not recommend it unless you know what you are doing and don't care about facing those issues. There are also people running Cassandra on Raspberry, so yes, it is doable and it is really up to you =). Good luck if you go this way. C*heers ----------------------- Alain Rodriguez - al...@thelastpickle.com France The Last Pickle - Apache Cassandra Consulting http://www.thelastpickle.com 2016-03-09 23:31 GMT+01:00 Jack Krupansky <jack.krupan...@gmail.com>: > Thanks, Rob, but... I'll continue to do my best to strongly (vehemently, > or is there an even stronger word for me to use?!) discourage use of > Cassandra in under 4/8 GB of memory. Hey, I just want people to be happy, > and trying to run Cassandra in under 8 GB (or 4 GB for dev) is just... > asking for trouble, unhappiness, even despair. Hey, if somebody is smart > enough to figure out how to do it on their own, then great, they are set > and don't need our help, but personally I would declare it as out of > bounds/off limits. But if anybody else here wants to support/encourage it, > they are free to do so and I won't get in their way other than to state my > own view. > > By "support", I primarily mean what the (open source) code does out of the > box without superhuman effort (BTW, all of the guys at Open Source > Connection ARE superhuman!!) as well as the support of memory of the > community here on this list. > > Doc? If anybody thinks there is a better source of doc for open source > Cassandra than the DataStax doc, please point me to it. Until then, I'll > stick with the DataStax doc > > That said, it might be interesting to have a no-memory/low-memory mode for > Cassandra which trades off performance for storage capacity. But... that > would be an enhancement, not something that is "supported" out of the box > today. What use cases would this satisfy? I mean, who is it that can get > away with sacrificing performance these days? > > -- Jack Krupansky > > On Mon, Mar 7, 2016 at 3:29 PM, Ben Bromhead <b...@instaclustr.com> wrote: > >> +1 for >> http://opensourceconnections.com/blog/2013/08/31/building- >> the-perfect-cassandra-test-environment/ >> <http://opensourceconnections.com/blog/2013/08/31/building-the-perfect-cassandra-test-environment/> >> >> >> We also run Cassandra on t2.mediums for our Developer clusters. You can >> force Cassandra to do most "memory" things by hitting the disk instead (on >> disk compaction passes, flush immediately to disk) and by throttling client >> connections. In fact on the t2 series memory is not the biggest concern, >> but rather the CPU credit issue. >> >> On Mon, 7 Mar 2016 at 11:53 Robert Coli <rc...@eventbrite.com> wrote: >> >>> On Fri, Mar 4, 2016 at 8:27 PM, Jack Krupansky <jack.krupan...@gmail.com >>> > wrote: >>> >>>> Please review the minimum hardware requirements as clearly documented: >>>> >>>> http://docs.datastax.com/en/cassandra/3.x/cassandra/planning/planPlanningHardware.html >>>> >>> >>> That is a document for Datastax Cassandra, not Apache Cassandra. It's >>> wonderful that Datastax provides docs, but Datastax Cassandra is a superset >>> of Apache Cassandra. Presuming that the requirements of one are exactly >>> equivalent to the requirements of the other is not necessarily reasonable. >>> >>> Please adjust your hardware usage to at least meet the clearly >>>> documented minimum requirements. If you continue to encounter problems once >>>> you have corrected your configuration error, please resubmit the details >>>> with updated hardware configuration details. >>>> >>> >>> Disagree. OP specifically stated that they knew this was not a >>> recommended practice. It does not seem unlikely that they are constrained >>> to use this hardware for reasons outside of their control. >>> >>> >>>> Just to be clear, development on less than 4 GB is not supported and >>>> production on less than 8 GB is not supported. Those are not suggestions or >>>> guidelines or recommendations, they are absolute requirements. >>>> >>> >>> What does "supported" mean here? That Datastax will not provide support >>> if you do not follow the above recommendations? Because it certainly is >>> "supported" in the sense of "it can be made to work" ... ? >>> >>> The premise of a minimum RAM level seems meaningless without context. >>> How much data are you serving from your 2GB RAM node? What is the rate of >>> client requests? >>> >>> To be clear, I don't recommend trying to run production Cassandra with >>> under 8GB of RAM on your node, but "absolute requirement" is a serious >>> overstatement. >>> >>> >>> http://opensourceconnections.com/blog/2013/08/31/building-the-perfect-cassandra-test-environment/ >>> >>> Has some good discussion of how to run Cassandra in a low memory >>> environment. Maybe someone should tell John that his 64MB of JVM heap for a >>> test node is 62x too small to be "supported"? :D >>> >>> =Rob >>> >>> -- >> Ben Bromhead >> CTO | Instaclustr <https://www.instaclustr.com/> >> +1 650 284 9692 >> Managed Cassandra / Spark on AWS, Azure and Softlayer >> > >
