Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange behaviour of small allocator #5216

Closed
alyapunov opened this issue Jul 29, 2020 · 0 comments · Fixed by #5503
Closed

Strange behaviour of small allocator #5216

alyapunov opened this issue Jul 29, 2020 · 0 comments · Fixed by #5503
Assignees
Labels
bug Something isn't working crash
Milestone

Comments

@alyapunov
Copy link
Contributor

Tarantool version: any

The code

box.cfg{wal_mode='none', memtx_memory=2*1024*1024*1024, listen=3301, memtx_min_tuple_size=32, slab_alloc_factor=1.03}

s = box.schema.space.create('test')
_ = s:create_index('test')

function str(i) return string.rep('a', math.floor(256 * math.pow(1.03, i))) end
for i=1,276 do s:replace{i+200, str(i)} end
for i=1,274 do s:delete{i+200} end
collectgarbage('collect')
s:replace{200+277, str(275)}
s:delete{200+275}
collectgarbage('collect')
s:delete{200+276}
collectgarbage('collect')

breaks debug version of tarantool:

tarantool: /home/alyapunov/Work/tarantool/src/lib/small/small/small.c:291: mempool_find: Assertion `size >= upper_bound->objsize_min' failed.
Aborted (core dumped)

and puts release version to unexpected state (see mem_used):

tarantool> box.slab.stats()[#box.slab.stats()-2]
---
- mem_free: 17654224
  mem_used: 18446744073708674504
  item_count: 3069965951
  item_size: 877112
  slab_count: 1
  slab_size: 16777216
...
@alyapunov alyapunov added the bug Something isn't working label Jul 29, 2020
@kyukhin kyukhin added the crash label Aug 14, 2020
@kyukhin kyukhin added this to the 2.5.3 milestone Aug 14, 2020
EvgenyMekhanik added a commit that referenced this issue Nov 5, 2020
Change small allocator behavior and add test for #5216 issue

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Nov 6, 2020
Change small allocator behavior and add test for #5216 issue

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Nov 9, 2020
Change small allocator behavior and add test for #5216 issue

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Nov 13, 2020
Change box/cfg test. Previously, if we set slab_alloc_factor > 2,
the small_alloc_create function quietly changed it to 2,
now I add assert slab_alloc_factor > 1.0 && slab_alloc_factor <= 2.

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Nov 13, 2020
Change box/cfg test. Previously, if we set slab_alloc_factor > 2,
the small_alloc_create function quietly changed it to 2,
now I add assert slab_alloc_factor > 1.0 && slab_alloc_factor <= 2.

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Nov 13, 2020
Add a check that the slab_alloc_factor is in the range
(1.0, 2.0] and if it is not so changed it to 1.0001 or 2.0
respectively

Closes #5216
@kyukhin kyukhin added the teamC label Nov 18, 2020
EvgenyMekhanik added a commit that referenced this issue Dec 7, 2020
Add a check that the slab_alloc_factor is in the range
(1.0, 2.0] and if it is not so changed it to 1.0001 or 2.0
respectively

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Dec 10, 2020
Add a check that the slab_alloc_factor is in the range
(1.0, 2.0] and if it is not so changed it to 1.0001 or 2.0
respectively

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Dec 10, 2020
Add a check that the slab_alloc_factor is in the range
(1.0, 2.0] and if it is not so changed it to 1.0001 or 2.0
respectively

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Dec 17, 2020
Add a check that the slab_alloc_factor is in the range
(1.0, 2.0] and if it is not so changed it to 1.0001 or 2.0
respectively

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Dec 17, 2020
Add a check that the slab_alloc_factor is in the range
(1.0, 2.0] and if it is not so changed it to 1.0001 or 2.0
respectively

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Dec 21, 2020
Previously, in small allocator, memory pools
were allocated at the request, which in the case
of a small slab_alloc_factor led to use
pools with incorrect sizes. This patch changed
small allocator behavior, now we allocate pools
on the stage of allocator creation. Also we use
special function to find appropriate pool, which
is faster, then previous version with rbtree.
This change fixes #5216.

Also moved a check, that the slab_alloc_factor is in
the range (1.0, 2.0] from small allocator to memtx_engine.
If factor is not in range change it to 1.0001 or 2.0 respectively

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Dec 22, 2020
Previously, in small allocator, memory pools
were allocated at the request, which in the case
of a small slab_alloc_factor led to use
pools with incorrect sizes. This patch changed
small allocator behavior, now we allocate pools
on the stage of allocator creation. Also we use
special function to find appropriate pool, which
is faster, then previous version with rbtree.
This change fixes #5216.

Also moved a check, that the slab_alloc_factor is in
the range (1.0, 2.0] from small allocator to memtx_engine.
If factor is not in range change it to 1.0001 or 2.0 respectively

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Dec 23, 2020
Previously, in small allocator, memory pools
were allocated at the request, which in the case
of a small slab_alloc_factor led to use
pools with incorrect sizes. This patch changed
small allocator behavior, now we allocate pools
on the stage of allocator creation. Also we use
special function to find appropriate pool, which
is faster, then previous version with rbtree.
This change fixes #5216.

Also moved a check, that the slab_alloc_factor is in
the range (1.0, 2.0] from small allocator to memtx_engine.
If factor is not in range change it to 1.0001 or 2.0 respectively

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Dec 24, 2020
Previously, in small allocator, memory pools
were allocated at the request, which in the case
of a small slab_alloc_factor led to use
pools with incorrect sizes. This patch changed
small allocator behavior, now we allocate pools
on the stage of allocator creation. Also we use
special function to find appropriate pool, which
is faster, then previous version with rbtree.
This change fixes #5216.

Also moved a check, that the slab_alloc_factor is in
the range (1.0, 2.0] from small allocator to memtx_engine.
If factor is not in range change it to 1.0001 or 2.0 respectively

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Dec 24, 2020
Previously, in small allocator, memory pools
were allocated at the request, which in the case
of a small slab_alloc_factor led to use
pools with incorrect sizes. This patch changed
small allocator behavior, now we allocate pools
on the stage of allocator creation. Also we use
special function to find appropriate pool, which
is faster, then previous version with rbtree.
This change fixes #5216.

Also moved a check, that the slab_alloc_factor is in
the range (1.0, 2.0] from small allocator to memtx_engine.
If factor is not in range change it to 1.0001 or 2.0 respectively

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Dec 24, 2020
Previously, in small allocator, memory pools
were allocated at the request, which in the case
of a small slab_alloc_factor led to use
pools with incorrect sizes. This patch changed
small allocator behavior, now we allocate pools
on the stage of allocator creation. Also we use
special function to find appropriate pool, which
is faster, then previous version with rbtree.
This change fixes #5216.

Also moved a check, that the slab_alloc_factor is in
the range (1.0, 2.0] from small allocator to memtx_engine.
If factor is not in range change it to 1.0001 or 2.0 respectively

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Dec 24, 2020
Previously, in small allocator, memory pools
were allocated at the request, which in the case
of a small slab_alloc_factor led to use
pools with incorrect sizes. This patch changed
small allocator behavior, now we allocate pools
on the stage of allocator creation. Also we use
special function to find appropriate pool, which
is faster, then previous version with rbtree.
This change fixes #5216.

Also moved a check, that the slab_alloc_factor is in
the range (1.0, 2.0] from small allocator to memtx_engine.
If factor is not in range change it to 1.0001 or 2.0 respectively

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Dec 24, 2020
Previously, in small allocator, memory pools
were allocated at the request, which in the case
of a small slab_alloc_factor led to use
pools with incorrect sizes. This patch changed
small allocator behavior, now we allocate pools
on the stage of allocator creation. Also we use
special function to find appropriate pool, which
is faster, then previous version with rbtree.
This change fixes #5216.

Also moved a check, that the slab_alloc_factor is in
the range (1.0, 2.0] from small allocator to memtx_engine.
If factor is not in range change it to 1.0001 or 2.0 respectively

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Dec 25, 2020
Previously, in small allocator, memory pools
were allocated at the request, which in the case
of a small slab_alloc_factor led to use
pools with incorrect sizes. This patch changed
small allocator behavior, now we allocate pools
on the stage of allocator creation. Also we use
special function to find appropriate pool, which
is faster, then previous version with rbtree.
This change fixes #5216.

Also moved a check, that the slab_alloc_factor is in
the range (1.0, 2.0] from small allocator to memtx_engine.
If factor is not in range change it to 1.0001 or 2.0 respectively

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Dec 25, 2020
Previously, in small allocator, memory pools
were allocated at the request, which in the case
of a small slab_alloc_factor led to use
pools with incorrect sizes. This patch changed
small allocator behavior, now we allocate pools
on the stage of allocator creation. Also we use
special function to find appropriate pool, which
is faster, then previous version with rbtree.
This change fixes #5216.

Also moved a check, that the slab_alloc_factor is in
the range (1.0, 2.0] from small allocator to memtx_engine.
If factor is not in range change it to 1.0001 or 2.0 respectively

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Dec 28, 2020
Previously, in small allocator, memory pools
were allocated at the request, which in the case
of a small slab_alloc_factor led to use
pools with incorrect sizes. This patch changed
small allocator behavior, now we allocate pools
on the stage of allocator creation. Also we use
special function to find appropriate pool, which
is faster, then previous version with rbtree.
This change fixes #5216.

Also moved a check, that the slab_alloc_factor is in
the range (1.0, 2.0] from small allocator to memtx_engine.
If factor is not in range change it to 1.0001 or 2.0 respectively

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Dec 29, 2020
Previously, in small allocator, memory pools
were allocated at the request, which in the case
of a small slab_alloc_factor led to use
pools with incorrect sizes. This patch changed
small allocator behavior, now we allocate pools
on the stage of allocator creation. Also we use
special function to find appropriate pool, which
is faster, then previous version with rbtree.
This change fixes #5216.

Also moved a check, that the slab_alloc_factor is in
the range (1.0, 2.0] from small allocator to memtx_engine.
If factor is not in range change it to 1.0001 or 2.0 respectively

Closes #5216
kyukhin pushed a commit that referenced this issue Dec 29, 2020
Previously, in small allocator, memory pools
were allocated at the request, which in the case
of a small slab_alloc_factor led to use
pools with incorrect sizes. This patch changed
small allocator behavior, now we allocate pools
on the stage of allocator creation. Also we use
special function to find appropriate pool, which
is faster, then previous version with rbtree.
This change fixes #5216.

Also moved a check, that the slab_alloc_factor is in
the range (1.0, 2.0] from small allocator to memtx_engine.
If factor is not in range change it to 1.0001 or 2.0 respectively

Closes #5216
EvgenyMekhanik added a commit that referenced this issue Dec 29, 2020
Previously, in small allocator, memory pools
were allocated at the request, which in the case
of a small slab_alloc_factor led to use
pools with incorrect sizes. This patch changed
small allocator behavior, now we allocate pools
on the stage of allocator creation. Also we use
special function to find appropriate pool, which
is faster, then previous version with rbtree.
This change fixes #5216.

Also moved a check, that the slab_alloc_factor is in
the range (1.0, 2.0] from small allocator to memtx_engine.
If factor is not in range change it to 1.0001 or 2.0 respectively

Closes #5216
kyukhin pushed a commit that referenced this issue Dec 29, 2020
Previously, in small allocator, memory pools
were allocated at the request, which in the case
of a small slab_alloc_factor led to use
pools with incorrect sizes. This patch changed
small allocator behavior, now we allocate pools
on the stage of allocator creation. Also we use
special function to find appropriate pool, which
is faster, then previous version with rbtree.
This change fixes #5216.

Also moved a check, that the slab_alloc_factor is in
the range (1.0, 2.0] from small allocator to memtx_engine.
If factor is not in range change it to 1.0001 or 2.0 respectively

Closes #5216

(cherry picked from commit 4d175bf)
kyukhin pushed a commit that referenced this issue Dec 29, 2020
Previously, in small allocator, memory pools
were allocated at the request, which in the case
of a small slab_alloc_factor led to use
pools with incorrect sizes. This patch changed
small allocator behavior, now we allocate pools
on the stage of allocator creation. Also we use
special function to find appropriate pool, which
is faster, then previous version with rbtree.
This change fixes #5216.

Also moved a check, that the slab_alloc_factor is in
the range (1.0, 2.0] from small allocator to memtx_engine.
If factor is not in range change it to 1.0001 or 2.0 respectively

Closes #5216

(cherry picked from commit 4d175bf)
kyukhin pushed a commit that referenced this issue Dec 29, 2020
Previously, in small allocator, memory pools
were allocated at the request, which in the case
of a small slab_alloc_factor led to use
pools with incorrect sizes. This patch changed
small allocator behavior, now we allocate pools
on the stage of allocator creation. Also we use
special function to find appropriate pool, which
is faster, then previous version with rbtree.
This change fixes #5216.

Also moved a check, that the slab_alloc_factor is in
the range (1.0, 2.0] from small allocator to memtx_engine.
If factor is not in range change it to 1.0001 or 2.0 respectively

Closes #5216
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working crash
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants