The only solution is to switch to arm64-capable multi-arch images. M1 Macs are capable of starting the image using architecture emulation, but Discourse is unlikely to boot due to the lack of inotify support in QEMU. The Discourse development docker image is only available for x86_64 architectures. Running it all through tmux to handle the differen shell instances. I just stopped and removed those containers and cloned the dev git repo into a different directory. usr/local/lib/ruby/2.7.0/fileutils.rb:250:in `mkdir': Permission denied dir_s_mkdir - /src/tmp (Errno::EACCES)Īny idea what’s going wrong? This machine previously ran a production discourse without issues.
#Postgres docker mac m1 install#
d/bundle install reports it needs sudo rights to install some, d/rails s also comes back with permission problems Traceback (most recent call last):ħ: from /src/bin/unicorn:38:in `ensure_cache_clean!'Ħ: from /usr/local/lib/ruby/2.7.0/fileutils.rb:211:in `mkdir_p'ĥ: from /usr/local/lib/ruby/2.7.0/fileutils.rb:211:in `each'Ĥ: from /usr/local/lib/ruby/2.7.0/fileutils.rb:226:in `block in mkdir_p'ģ: from /usr/local/lib/ruby/2.7.0/fileutils.rb:226:in `reverse_each'Ģ: from /usr/local/lib/ruby/2.7.0/fileutils.rb:228:in `block (2 levels) in mkdir_p'ġ: from /usr/local/lib/ruby/2.7.0/fileutils.rb:250:in `fu_mkdir'
Write, close, fsync 4810.I switched from my local Mac to a Ubuntu VM hoping this would make it easier to get this running but unfortunately so far it’s not.Īlready fighting some weird permission problems in the early stages. Write, fsync, close 5117.824 ops/sec 195 usecs/op
I feel like the average transaction commit time is quite high (33ms) as well as logging transaction time (38ms). Most of the time is spent waiting for confirmation on journal writes.
While running I watched /proc/pid/wchan which contained jbd2_log_wait_commit most of the time. Differences are insane (I never finished execution inside a VM). I created a simple program that just opens a file with O_SYNC and writes 1GB to disk in 10kB chunks. I have no idea if the things that looked interesting to me are actually relevant or if my interpretation is correct by any means 😄 I tried to identify interesting metrics, mostly by searching for related issues and experimenting with different trace events. Write, close, fsync 25.647 ops/sec 38991 usecs/op Write, fsync, close 25.349 ops/sec 39449 usecs/op O_DIRECT supported on this platform for open_datasync and open_sync. Write, close, fsync 30637,555 ops/sec 33 usecs/opĭocker run postgres /usr/lib/postgresql/13/bin/pg_test_fsync Write, fsync, close 17635,059 ops/sec 57 usecs/op (If the times are similar, fsync() can sync data written on a different Test if fsync on non-write file descriptor is honored: (This is designed to compare the cost of writing 16kB in different writeġ * 16kB open_sync write 49191,864 ops/sec 20 usecs/opĢ * 8kB open_sync writes 23965,957 ops/sec 42 usecs/opĤ * 4kB open_sync writes 12443,790 ops/sec 80 usecs/opĨ * 2kB open_sync writes 6311,889 ops/sec 158 usecs/opġ6 * 1kB open_sync writes 3162,668 ops/sec 316 usecs/op Open_datasync 23969,437 ops/sec 42 usecs/opįsync_writethrough 54,774 ops/sec 18257 usecs/opĬompare open_sync with different write sizes: Open_datasync 25096,743 ops/sec 40 usecs/opįsync_writethrough 55,117 ops/sec 18143 usecs/opĬompare file sync methods using two 8kB writes: (in wal_sync_method preference order, except fdatasync is Linux's default) opt/homebrew/Cellar/postgresql/13.2/bin/pg_test_fsyncĭirect I/O is not supported on this platform.Ĭompare file sync methods using one 8kB write:
0 kommentar(er)
