Re: End of life policy
I guess that's fair. On Wed, 8 Jul 2020, Nicolas Motte wrote: > Thx Dormando! > I ll then use this rule for the time being: > > - 1.4 is dead > - 1.5 is still supported (in the sense that a major security issue could be > fixed) > - 1.6 is the preferred version > > Cheers > Nico > > > On Wed, Jul 8, 2020 at 9:51 AM dormando wrote: > Hey, > > In extreme cases we would provide patches, and there's nothing stopping > me > from releasing a new 1.5 version. Most distro's just patch what versions > they maintain, which is a wide swath of them. > > The only difference between later 1.4 and early 1.5 versions were the > defaults enabled, so releasing more 1.4's had no point. > > I think the one CVE that's happened since 1.6 came out only affected > 1.6+. > 1.6 is also not a huge jump. > > In short, nobody's asked for one, so I havent't done one, I guess. The > project moves pretty slowly and conservatively so I don't personally > view > the dot versions to be something people should hold onto dearly. It just > makes things harder when something goes go wrong since they have less > observability and miss out on bug fixes. > > On Wed, 8 Jul 2020, Nicolas Motte wrote: > > > Hi everyone, > > I d like to know what is the end of life policy for major memcached > versions. > > > > At the moment we re using 1.4 and 1.5. Looking at the release notes, > it feels like only the latest major version (1.6) has new releases, > which makes me > > think in case of a security issue found on a previous major version, > it would not be fixed and we would have to migrate to 1.6. > > > > It would mean the policy is simple (but a bit drastic) : "every time > a new major version is released, the previous one is dead." > > > > Is my understanding correct? > > > > Cheers > > Nico > > > > -- > > > > --- > > You received this message because you are subscribed to the Google > Groups "memcached" group. > > To unsubscribe from this group and stop receiving emails from it, > send an email to memcached+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/memcached/CAB7O_Y_BN%2BewH-z%3DqCe2LGMU_Qj7nuZ9fHp9K-jWsDrbUhfTLQ%40mail.gmail.com. > > > > > > -- > > --- > You received this message because you are subscribed to the Google > Groups "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to memcached+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.2007080043570.18887%40dskull. > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to memcached+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/memcached/CAB7O_Y-XUJhyL-gVmCGHfRDTqqHvSvpD6A4xzPjmA_B%2BF6B-6Q%40mail.gmail.com. > > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.2007080144460.18887%40dskull.
Re: End of life policy
Thx Dormando! I ll then use this rule for the time being: - 1.4 is dead - 1.5 is still supported (in the sense that a major security issue could be fixed) - 1.6 is the preferred version Cheers Nico On Wed, Jul 8, 2020 at 9:51 AM dormando wrote: > Hey, > > In extreme cases we would provide patches, and there's nothing stopping me > from releasing a new 1.5 version. Most distro's just patch what versions > they maintain, which is a wide swath of them. > > The only difference between later 1.4 and early 1.5 versions were the > defaults enabled, so releasing more 1.4's had no point. > > I think the one CVE that's happened since 1.6 came out only affected 1.6+. > 1.6 is also not a huge jump. > > In short, nobody's asked for one, so I havent't done one, I guess. The > project moves pretty slowly and conservatively so I don't personally view > the dot versions to be something people should hold onto dearly. It just > makes things harder when something goes go wrong since they have less > observability and miss out on bug fixes. > > On Wed, 8 Jul 2020, Nicolas Motte wrote: > > > Hi everyone, > > I d like to know what is the end of life policy for major memcached > versions. > > > > At the moment we re using 1.4 and 1.5. Looking at the release notes, it > feels like only the latest major version (1.6) has new releases, which > makes me > > think in case of a security issue found on a previous major version, it > would not be fixed and we would have to migrate to 1.6. > > > > It would mean the policy is simple (but a bit drastic) : "every time > a new major version is released, the previous one is dead." > > > > Is my understanding correct? > > > > Cheers > > Nico > > > > -- > > > > --- > > You received this message because you are subscribed to the Google > Groups "memcached" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to memcached+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/memcached/CAB7O_Y_BN%2BewH-z%3DqCe2LGMU_Qj7nuZ9fHp9K-jWsDrbUhfTLQ%40mail.gmail.com > . > > > > > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to memcached+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.2007080043570.18887%40dskull > . > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/memcached/CAB7O_Y-XUJhyL-gVmCGHfRDTqqHvSvpD6A4xzPjmA_B%2BF6B-6Q%40mail.gmail.com.
Re: End of life policy
Hey, In extreme cases we would provide patches, and there's nothing stopping me from releasing a new 1.5 version. Most distro's just patch what versions they maintain, which is a wide swath of them. The only difference between later 1.4 and early 1.5 versions were the defaults enabled, so releasing more 1.4's had no point. I think the one CVE that's happened since 1.6 came out only affected 1.6+. 1.6 is also not a huge jump. In short, nobody's asked for one, so I havent't done one, I guess. The project moves pretty slowly and conservatively so I don't personally view the dot versions to be something people should hold onto dearly. It just makes things harder when something goes go wrong since they have less observability and miss out on bug fixes. On Wed, 8 Jul 2020, Nicolas Motte wrote: > Hi everyone, > I d like to know what is the end of life policy for major memcached versions. > > At the moment we re using 1.4 and 1.5. Looking at the release notes, it feels > like only the latest major version (1.6) has new releases, which makes me > think in case of a security issue found on a previous major version, it would > not be fixed and we would have to migrate to 1.6. > > It would mean the policy is simple (but a bit drastic) : "every time a new > major version is released, the previous one is dead." > > Is my understanding correct? > > Cheers > Nico > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to memcached+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/memcached/CAB7O_Y_BN%2BewH-z%3DqCe2LGMU_Qj7nuZ9fHp9K-jWsDrbUhfTLQ%40mail.gmail.com. > > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.2007080043570.18887%40dskull.
End of life policy
Hi everyone, I d like to know what is the end of life policy for major memcached versions. At the moment we re using 1.4 and 1.5. Looking at the release notes, it feels like only the latest major version (1.6) has new releases, which makes me think in case of a security issue found on a previous major version, it would not be fixed and we would have to migrate to 1.6. It would mean the policy is simple (but a bit drastic) : "*every time a new major version is released, the previous one is dead.*" Is my understanding correct? Cheers Nico -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/memcached/CAB7O_Y_BN%2BewH-z%3DqCe2LGMU_Qj7nuZ9fHp9K-jWsDrbUhfTLQ%40mail.gmail.com.
Re: Total memory allocated with -m NOT EQUAL to (total pages * max_item_size). Request to provide clarification on how page size works.
>Your evictions are literally zero, in these stats. You saw them before, when the instances were smaller? Yes we have seen it and it impacted the business as well. >There're a maximum of 63 classes, so making the number smaller has a limited effect. The more slab classes you have, the harder the automove balancer has to work to keep things even. I don't really recommend adjusting the value much if at all. Understood. Thank you for the details. >All you probably had to do was turn on automove, but I don't have your stats from when you did have evictions so I can't say for sure. I understand. Thanks a lot for your time and valuable inputs. Will capture stats for sure if we face the issue again and then it should be better to analyse. Grateful to you for your inputs and time. It helped. :). Cheers to Team Memcached for the great product :) Thank you, Shweta On Wednesday, July 8, 2020 at 11:27:09 AM UTC+5:30, Dormando wrote: > > > >Also your instance hasn't even malloc'ed half of its memory limit. You > > have over 6 gigabytes unused. There aren't any evictions despite the > > uptime being over two months. > > Was eviction of active items expeted as well? We have eviction of unsed > and unfetched items. > > Your evictions are literally zero, in these stats. You saw them before, > when the instances were smaller? > > > >Otherwise: > > 1. is the default in 1.5 anyway > > 2. is the default in 1.5. > > 3. don't bother changing this; it'll change the way the slabs scale. > > 4. 1.20 is probably fine. reducing it only helps if you have very > little > > memory. > > 5. also fine. > > > Does increasing slab classes by reducing growth factor affect > > performance? I understand if we have more slab classes it can help in > > increasing storage overhead as less memory as we may find chunk size > closer to item size. > > There're a maximum of 63 classes, so making the number smaller has a > limited effect. The more slab classes you have, the harder the automove > balancer has to work to keep things even. I don't really recommend > adjusting the value much if at all. > > All you probably had to do was turn on automove, but I don't have your > stats from when you did have evictions so I can't say for sure. > > > >If it were full and automove was off like it is now, you would see > > problems over time. Noted.Thank you for the input. :) > > > > Thank you, > > Shweta > > > > On Wednesday, July 8, 2020 at 10:00:30 AM UTC+5:30, Dormando wrote: > > you said you were seeing evictions? Was this on a different > instance? > > > > I don't really have any control or influence over what amazon > deploys for > > elasticache. They've also changed the daemon. Some of your > settings are > > different from the defaults that 1.5.10 has (automove should > default to 1 > > and hash_Algo should default to murmur). > > > > Also your instance hasn't even malloc'ed half of its memory limit. > You > > have over 6 gigabytes unused. There aren't any evictions despite > the > > uptime being over two months. > > > > So far as I can see you don't have to do anything? Unless a > different > > instance was giving you trouble. > > > > Otherwise: > > 1. is the default in 1.5 anyway > > 2. is the default in 1.5. > > 3. don't bother changing this; it'll change the way the slabs > scale. > > 4. 1.20 is probably fine. reducing it only helps if you have very > little > > memory. > > 5. also fine. > > > > but mainly 1) I can't really guarantee anything I say has > relevance since > > I don't know what code is in elasticache and 2) your instance > isn't even > > remotely full so I don't have any recommendations. > > > > If it were full and automove was off like it is now, you would see > > problems over time. > > > > On Tue, 7 Jul 2020, Shweta Agrawal wrote: > > > > > yes > > > > > > On Wednesday, July 8, 2020 at 9:35:19 AM UTC+5:30, Dormando > wrote: > > > Oh, so this is amazon elasticache? > > > > > > On Tue, 7 Jul 2020, Shweta Agrawal wrote: > > > > > > > We use aws for deployment and don't have that > information. What particularly looks odd in settings? > > > > > > > > On Wednesday, July 8, 2020 at 8:10:04 AM UTC+5:30, > Dormando wrote: > > > > what're your start arguments? the settings look a > little odd. ie; the full > > > > commandline (censoring anything important) that > you used to start > > > > memcached > > > > > > > > On Tue, 7 Jul 2020, Shweta Agrawal wrote: > > > > > > > > > Sorry. Here it is. > > > > > > > > > > On Wednesday, July 8, 2020 at
