Deuxfleurs/garage
42
42
Fork 58
Code Issues 80 Pull requests 8 Releases 29 Wiki Activity

0.8.1: Heavy data directory reading after upgrade #470

New issue
Closed
opened 2023-01-09 17:46:25 +00:00 by jpds · 2 comments
jpds commented 2023-01-09 17:46:25 +00:00
Contributor
Copy link

I upgraded my cluster from 0.7.2 to 0.8.1, and followed all the steps at: https://garagehq.deuxfleurs.fr/documentation/working-documents/migration-08/

There's currently zero S3/web activity on the cluster nor anything in the queues, but I'm observating a lot of disk reading:

$ zpool iostat 1
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
garage       132G   4.4T      5      0  2.33M      0
zroot       7.46G   225G      0      5      0   447K
----------  -----  -----  -----  -----  -----  -----
garage       132G   4.4T      6      0  3.08M      0
zroot       7.46G   225G      0     70      0   575K
----------  -----  -----  -----  -----  -----  -----
garage       132G   4.4T     13      0  2.94M      0
zroot       7.46G   225G      0      5      0   469K
----------  -----  -----  -----  -----  -----  -----
garage       132G   4.4T     13      0  4.59M      0
zroot       7.46G   225G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----
garage       132G   4.4T      5      0  3.39M      0
zroot       7.46G   225G      0      5      0   384K
----------  -----  -----  -----  -----  -----  -----
garage       132G   4.4T      6      0  5.01M      0
zroot       7.46G   225G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----
garage       132G   4.4T      6      0  5.39M      0
zroot       7.46G   225G      0     78      0  1.02M
----------  -----  -----  -----  -----  -----  -----
garage       132G   4.4T      7      0  4.99M      0
zroot       7.46G   225G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----
garage       132G   4.4T      6      0  5.66M      0
zroot       7.46G   225G      0      5      0   456K
----------  -----  -----  -----  -----  -----  -----
garage       132G   4.4T     13      0  6.97M      0
zroot       7.46G   225G      0      0      0  3.98K
----------  -----  -----  -----  -----  -----  -----
garage       132G   4.4T      8      0  3.19M      0
zroot       7.46G   225G      0      4      0   382K
----------  -----  -----  -----  -----  -----  -----

If I probe DTrace for things being opened, it seems garage is crawling its own data directory:

$ dtrace -n 'syscall::open*:entry { printf("%s %s", execname, copyinstr(arg0)); }'
  2  82631                       open:entry garage /srv/garage/20/c5
  2  82631                       open:entry garage /srv/garage/20/d2
  3  82631                       open:entry garage /srv/garage/20/ad
  2  82631                       open:entry garage /srv/garage/20/fc
  3  82631                       open:entry garage /srv/garage/20/d8
  3  82631                       open:entry garage /srv/garage/20/7a
...  
  2  82631                       open:entry garage /srv/garage/7f/8c
  0  82631                       open:entry garage /srv/garage/7f/46
  0  82631                       open:entry garage /srv/garage/7f/31
  2  82631                       open:entry garage /srv/garage/7f/b3
  1  82631                       open:entry garage /srv/garage/7f/e4
  3  82631                       open:entry garage /srv/garage/7f/e9
...
  0  82631                       open:entry garage /srv/garage/0a/9d
  0  82631                       open:entry garage /srv/garage/0a/51
  1  82631                       open:entry garage /srv/garage/0a/26
  1  82631                       open:entry garage /srv/garage/0a/ae
  1  82631                       open:entry garage /srv/garage/0a/fb
  0  82631                       open:entry garage /srv/garage/0a/d9

Is there something else I can try to debug where this is coming from?

I upgraded my cluster from `0.7.2` to `0.8.1`, and followed all the steps at: https://garagehq.deuxfleurs.fr/documentation/working-documents/migration-08/ There's currently zero S3/web activity on the cluster nor anything in the queues, but I'm observating a lot of disk reading: ``` $ zpool iostat 1 capacity operations bandwidth pool alloc free read write read write ---------- ----- ----- ----- ----- ----- ----- garage 132G 4.4T 5 0 2.33M 0 zroot 7.46G 225G 0 5 0 447K ---------- ----- ----- ----- ----- ----- ----- garage 132G 4.4T 6 0 3.08M 0 zroot 7.46G 225G 0 70 0 575K ---------- ----- ----- ----- ----- ----- ----- garage 132G 4.4T 13 0 2.94M 0 zroot 7.46G 225G 0 5 0 469K ---------- ----- ----- ----- ----- ----- ----- garage 132G 4.4T 13 0 4.59M 0 zroot 7.46G 225G 0 0 0 0 ---------- ----- ----- ----- ----- ----- ----- garage 132G 4.4T 5 0 3.39M 0 zroot 7.46G 225G 0 5 0 384K ---------- ----- ----- ----- ----- ----- ----- garage 132G 4.4T 6 0 5.01M 0 zroot 7.46G 225G 0 0 0 0 ---------- ----- ----- ----- ----- ----- ----- garage 132G 4.4T 6 0 5.39M 0 zroot 7.46G 225G 0 78 0 1.02M ---------- ----- ----- ----- ----- ----- ----- garage 132G 4.4T 7 0 4.99M 0 zroot 7.46G 225G 0 0 0 0 ---------- ----- ----- ----- ----- ----- ----- garage 132G 4.4T 6 0 5.66M 0 zroot 7.46G 225G 0 5 0 456K ---------- ----- ----- ----- ----- ----- ----- garage 132G 4.4T 13 0 6.97M 0 zroot 7.46G 225G 0 0 0 3.98K ---------- ----- ----- ----- ----- ----- ----- garage 132G 4.4T 8 0 3.19M 0 zroot 7.46G 225G 0 4 0 382K ---------- ----- ----- ----- ----- ----- ----- ``` If I probe DTrace for things being opened, it seems `garage` is crawling its own data directory: ``` $ dtrace -n 'syscall::open*:entry { printf("%s %s", execname, copyinstr(arg0)); }' 2 82631 open:entry garage /srv/garage/20/c5 2 82631 open:entry garage /srv/garage/20/d2 3 82631 open:entry garage /srv/garage/20/ad 2 82631 open:entry garage /srv/garage/20/fc 3 82631 open:entry garage /srv/garage/20/d8 3 82631 open:entry garage /srv/garage/20/7a ... 2 82631 open:entry garage /srv/garage/7f/8c 0 82631 open:entry garage /srv/garage/7f/46 0 82631 open:entry garage /srv/garage/7f/31 2 82631 open:entry garage /srv/garage/7f/b3 1 82631 open:entry garage /srv/garage/7f/e4 3 82631 open:entry garage /srv/garage/7f/e9 ... 0 82631 open:entry garage /srv/garage/0a/9d 0 82631 open:entry garage /srv/garage/0a/51 1 82631 open:entry garage /srv/garage/0a/26 1 82631 open:entry garage /srv/garage/0a/ae 1 82631 open:entry garage /srv/garage/0a/fb 0 82631 open:entry garage /srv/garage/0a/d9 ``` Is there something else I can try to debug where this is coming from?
lx commented 2023-01-09 18:00:31 +00:00
Owner
Copy link

Probably your node is doing a scrub of the stored data to check for corruptions. It does it once every month. It's meant to be a background process that limits itself in terms of I/O in order to leave space for interactive requests to be served first. You can check the progress of the scrub using garage worker list and garage worker info. You can change the speed of the scrub using garage worker set scrub-tranquility (zero is the fastest possible, larger values mean more interval between iterations and therefore a smaller proportion of I/O time used by the scrub).

Probably your node is doing a scrub of the stored data to check for corruptions. It does it once every month. It's meant to be a background process that limits itself in terms of I/O in order to leave space for interactive requests to be served first. You can check the progress of the scrub using `garage worker list` and `garage worker info`. You can change the speed of the scrub using `garage worker set scrub-tranquility` (zero is the fastest possible, larger values mean more interval between iterations and therefore a smaller proportion of I/O time used by the scrub).
jpds commented 2023-01-09 18:07:06 +00:00
Author
Contributor
Copy link

Very interesting - that was indeed it.

Very interesting - that was indeed it.
jpds closed this issue 2023-01-09 18:19:05 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
hotfix/1.0.0-rc1-red-ftr-wquorum
main-0.9.x
db-no-unsafe
main-0.8.x
k2v/shared_http_client
feat/website-redir
smithy2
test/compilation
poc/nomad-ci
test-ci-wait
pnet_datalink-0.33.0
optimal-layout
k2v-watch-range
db-debug-log
build-convert-db
demonstrate-cargo2nix-bug
dangerous/no-fsync
dev0.7.3
doc/benchmarks
bug/check_static
bucket-cors-more
storage-optimizations
old-main
v1.0.0
v0.9.4
v1.0.0-rc1
v0.8.7
v0.9.3
v0.9.2
v0.8.6
v0.9.2-rc1
v0.9.1
v0.8.5
v0.10.0-beta1
v0.9.0
v0.9.0-rc2
v0.9.0-rc1
v0.9.0-beta4
v0.9.0-beta3
v0.9.0-beta2
v0.8.4
v0.9.0-beta1
v0.8.3
v0.8.3-rc1
format_table-v0.1.1
format_table-v0.1.0
v0.8.2
v0.8.1
v0.8.0
v0.8.0-rc2
v0.8.0-rc1
v0.8.0-dangerous-no-fsync
v0.8.0-beta2-k2v
v0.8.0-beta2
v0.8.0-beta1-k2v
v0.8.0-beta1
v0.7.99.3-k2v
v0.7.3
v0.7.3-beta2
v0.7.3-beta1
v0.7.2.1
v0.7.2
v0.7.2_ci-test-2
v0.7.2+ci-test-version
v0.7.99.2-k2v
v0.7.99.1-k2v
v0.7.99-k2v
v0.7.2-k2v
v0.7.1-admin-k2v-2
v0.7.1-admin-k2v
v0.7.1-k2v
v0.7.1
v0.7.0
v0.7.0-rc1
v0.6.1
v0.6.0
v0.6.0-rc1
v0.5.1
v0.5.0.1
v0.5.0
v0.5-beta1
v0.4.0
v0.4-rc2
v0.4-rc1
0.4-beta
0.4-alpha
v0.3.0.2
v0.3.0.1
v0.3.0
v0.2.1.5
v0.2.1
v0.2.0
0.1.1b
0.1.1
0.1.0b
0.1.0
Labels
Clear labels   
AdminAPI

Issues concerning the administration API

  
Bug

   
Check AWS

The behaviour should be checked against AWS S3

  
CI

Issues with Nix, Drone, Rust Compiler, etc.

  
Correctness

Issues of theoretical correctness that may impact edge-case scenarios

  
Critical

   
Documentation

   
Ideas

For abstract ideas/proposal to make Garage better, to better communicate our not yet achieved aims

  
Improvement

   
Low priority

For issues that we don't want to spend time on until made absolutely necessary

  
Newcomer

A bug that should be newcomer friendly.

  
Performance

   
S3 Compatibility

   
Testing

   
Usability

Propositions to make Garage easier to operate, by improving error reporting, CLI, etc.

No labels
AdminAPI
Bug
Check AWS
CI
Correctness
Critical
Documentation
Ideas
Improvement
Low priority
Newcomer
Performance
S3 Compatibility
Testing
Usability
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Deuxfleurs/garage#470
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?