As a developer using a current generation Mac, I can’t run Singlestore locally, including docker, because there’s no arm64 version available.
When making a decision about which database to use for new projects, being able to develop against it locally, either using testcontainers or the cluster in a box solution is a binary go / no go. So it’s a no. I’ll have to use a different data store.
WWDC has been announced, and with it the new Macbook Pros that every developer will choose in the foreseeable future.
Additional upside is being able to run on Graviton AWS instances (which we foresee all our EKS clusters being), and the rest of the arm ecosystem.
The only other reference I found to arm on the forum was a post about Graviton instances, and the reply included that it’s recommended to use Intel processors because Singlestore can make use of the AVX2 instruction set. Guessing a look at that or an equivalent may be worthwhile, but in the mean time if that’s optional, it’d be good to get started with a local container that just works.
For testing and development, consider using our managed service free trial if you run on an ARM-based Mac.
We also have free developer options under consideration for our managed service that won’t be time limited but will be limited in scale and availability SLA – stay tuned for more information on that.
SingleStore uses Intel AVX2 SIMD instructions and we generate machine code for every query, so we benefit a lot from running on Intel processors. Plus, in the cloud, it’s easy to get access to Intel and Intel-compatible processors. That’s the rationale for not jumping on ARM right away. But we will keep an eye on these requirements and consider it for the future.
As I’m sure you’re aware, ARM offers the best cost/performance in the cloud.
Arm instances perform better with “close to metal” applications.
Across the board, Graviton2 offers better cost/performance vs. Intel x86 CPUs.
We hypothesize that the baseline Linux operating system is already optimized for ARM CPUs, allowing native binaries to take full advantage of Graviton2’s performance features. However, framework and runtime software higher in the stack, such as Node.js and SSVM, are not specifically optimized for Arm CPUs due to Arm’s relative newness in the server and cloud space. There is still significant room for improvement in Arm versions of server-side software.
It has been a long journey getting here — we first started testing Arm CPUs all the way back in November 2017. It’s only recently, however, that the quantum of energy efficiency improvement from Arm has become clear. Our first deployment of an Arm-based CPU, designed by Ampere, was earlier this month – July 2021.
Same problem. Our test flow is relying on testcontainers as best practice not to use a real DB instance that can have conflicts during the tests. We are not willing to manage the DB state just for the tests and willing to have an isolated test env as should be.
Not having the option to run the cluster-in-a-box on apple M1 computers is really painful.
Maybe a graceful degradation option would be ok in this scenario. A performance loss (due the non native query) in exchange for working on ARM based architectures. This should be enough for local development purposes.
I’ve been trying to configure the docker image to run on M1 mac using the
parameter:
platform=linux/amd64
in the yaml docker configuration file.
and a docker file containing
FROM --platform=linux/amd64 memsql
But it still doesn’t work.
I tested this approach with a MySQL docker image, which works fine and runs in the emulated amd64 modus.
When looking at the docker dashboard in the container / apps section, there is a label ‘amd64’ below the MySQL app.
For the Singlestore container, I have the same label, so suspecting the image + container has been created in an emulated amd64 modus.
But when I launch the container with docker-compose up, the process bails out.
This is the log from the terminal:
Attaching to memsql_1
memsql_1 | 2022-01-07 14:00:37.527041 Starting Cluster
memsql_1 | Latest errors from MemSQL tracelog:
memsql_1 | 578 2022-01-07 14:00:39.613 INFO: Log opened
memsql_1 | 02431423 2022-01-07 14:00:42.044 FAIL: Thread 115118: InitializeRepl: Failed to initialize replication subsystem because 'io_setup' system call failed with error 38 (Function not implemented).
memsql_1 | : Failed to connect to MemSQL: process exited: exit status 255
memsql_1 | Traceback (most recent call last):
memsql_1 | File "/startup", line 122, in <module>
memsql_1 | start_cluster()
memsql_1 | File "/startup", line 86, in start_cluster
memsql_1 | ctl("start-node", "--all")
memsql_1 | File "/startup", line 18, in ctl
memsql_1 | subprocess.check_output(["memsqlctl", "-yj"] + list(args)))
memsql_1 | File "/usr/lib64/python2.7/subprocess.py", line 575, in check_output
memsql_1 | raise CalledProcessError(retcode, cmd, output=output)
memsql_1 | subprocess.CalledProcessError: Command '['memsqlctl', '-yj', 'start-node', '--all']' returned non-zero exit status 1
memsql_1 exited with code 1
Anyone a clue on how to get Singlestore running on Apple M1 chipset in a docker container?
@hanson, “keeping an eye”, does this mean this is on the roadmap?
Would it work running singlestore within a virtualized windows environment like parallels?
This is a showstopper for my team. While I understand the desire to operate on the optimal hardware for your platform, your product is literally unusable for many small teams and hobbyists who cannot, or simply will not accept the necessity of a managed service or alternate hardware to run a database. Coupled with the fact that other databases do not have this problem, it is a significant mark against SingleStore. Surely this had to have come up in house too?
The % of M1 machines is only going to increase over time, and it’s fairly troubling that this doesn’t seem to be a high priority , but just something to ‘keep an eye on’. The less people can try your product before committing, the less they will be willing to explore the product further.
ARM support and M1 support are critical to development and production use of SingleStore. We are actively working on supporting M1 chips, but supporting ARM overall (including Graviton instances) is a longer-term effort but we are exploring it as we understand the performance benefits of deploying software on those.
We are happy to provide $500 in free credits for use of our Managed Service for development purposes, in addition to more credits when you collaborate with SingleStore Solution Engineers.
Would you be interested in further pursuing this path?
Hey to all those within this thread! I myself run Apple Silicon and wanted to get it running, after a week of back and forth testing… I finally got it functional!
Now granted, this is not official nor supported by the SingleStore team, however it gives a taster for those wanting to tinker with it.
