From: Vladimir Davydov <vdavydov.dev@gmail.com> To: Konstantin Osipov <kostja@tarantool.org> Cc: tarantool-patches@freelists.org Subject: Re: [PATCH] Allow to increase box.cfg.vinyl_memory and memtx_memory at runtime Date: Wed, 30 May 2018 19:08:25 +0300 [thread overview] Message-ID: <20180530160825.say4ia6morjcme6k@esperanza> (raw) In-Reply-To: <20180530154107.GA14567@atlas> On Wed, May 30, 2018 at 06:41:07PM +0300, Konstantin Osipov wrote: > * Vladimir Davydov <vdavydov.dev@gmail.com> [18/05/30 15:55]: > > Closes #2634 > > --- > > https://github.com/tarantool/tarantool/issues/2634 > > https://github.com/tarantool/tarantool/commits/gh-2634-allow-to-increase-memory-size > > It should still be possible to set the limit to the same size, > what do you think? It is possible - box.cfg{memtx_memory = box.cfg.memtx_memory} works with this patch. > > +int > > +memtx_engine_set_memory(struct memtx_engine *memtx, size_t size) > > +{ > > + if (size < quota_total(&memtx->quota)) { > > Shouldn't this be <= rather than < ? I don't think so - we shouldn't raise error if the new limit equals the current one. > > > + diag_set(ClientError, ER_CFG, "memtx_memory", > > + "cannot decrease memory size at runtime"); > > + return -1; > > + } > > + quota_set(&memtx->quota, size); > > + return 0; > > +} > > +int > > +vinyl_engine_set_memory(struct vinyl_engine *vinyl, size_t size) > > +{ > > + if (size < vinyl->env->quota.limit) { > > Same here. > > > + diag_set(ClientError, ER_CFG, "vinyl_memory", > > + "cannot decrease memory size at runtime"); > > + return -1; > > + } > > + vy_quota_set_limit(&vinyl->env->quota, size); > > + return 0; > > +} > > > > /** > > index 00000000..e3e89393 > > --- /dev/null > > +++ b/test/box/lua/cfg_memory.lua > > @@ -0,0 +1,9 @@ > > +#!/usr/bin/env tarantool > > Adding wal_mode=none will speed things up a bit when testing for > memtx at least. > > Similar tests reside in wal_mode suite. OK, I'll move the test to wal_off suite. > > > + > > +local LIMIT = tonumber(arg[1]) > > + > > +box.cfg{ > > + memtx_memory = LIMIT, > > +} > > + > > +--- > > +- error: 'Incorrect value for option ''memtx_memory'': cannot decrease memory size > > + at runtime' > > +... > > +box.slab.info().quota_size > > +--- > > +- 268435456 > > As usual, I'd prefer a less cpu intensive test. E.g. do you have > to double the amount of memory ? Perhaps only slightly increasing it > would test the same even better? > The same remark applies to vinyl test. OK, I'll try to tune the test.
next prev parent reply other threads:[~2018-05-30 16:08 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-30 12:55 Vladimir Davydov 2018-05-30 15:41 ` Konstantin Osipov 2018-05-30 16:08 ` Vladimir Davydov [this message] 2018-05-30 16:43 ` [PATCH v2] " Vladimir Davydov 2018-05-30 17:23 ` Konstantin Osipov 2018-06-01 18:48 ` Konstantin Osipov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180530160825.say4ia6morjcme6k@esperanza \ --to=vdavydov.dev@gmail.com \ --cc=kostja@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='Re: [PATCH] Allow to increase box.cfg.vinyl_memory and memtx_memory at runtime' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox