Is MultiChain current build prepared to process a large amount of transactions?

Question

Im testing MultiChain and I will be using it on a public entity on my country as a TimeStamp service.

Today I got this:

Aug 22 15:54:41 multichain-test kernel: [743058.944750] multichaind[24556]: segfault at 0 ip 000000000066e077 sp 00007fb7e0cf8390 error 4 in multichaind[400000+7ed000]

I wonder if you would recommend the current build (1.0-alpha-23) for this usage or if maybe its too unstable to use in production.

Thank you very much

Answer 1

We spent a while trying to reproduce this crash on your data files, but unfortunately we could not. The only possible suggestion is that you are running MultiChain on a very RAM-limited server, i.e. less than 256 MB.

From the next version we will distribute MultiChain with more embedded debugging information, which will enable us to use messages of the type you saw to determine which line of code the problem happened in.

In the meantime based on the loads in your data files, you weren't doing anything remotely near MultiChain's limits, so this appears to be a straightforward bug we just need to fix.

Comments

I thought that too, the server is 1GB ram, single core CPU,  Digital Ocean droplet.

---

Any idea how much RAM it had available for MultiChain?

---

about ~600 mb

---

It sounds fine. We've set things up so it's easier for us to debug these kinds of problems in future, by relating the message you received back to our code. But unfortunately not in time for this release. For now I suggest you keep using MultiChain, since this should be a rare occurrence.

Answer 2

What transaction throughput were you pushing through it? This sounds like a straightforwards bug we should fix. Are you able to zip up the blockchain directory (inside ~/.multichain/) for the server this happened on, and send it to us at multichain.debug ar gmail.com?

Comments

Yes, will send it

---

Thanks, we're taking a look.

---

Already sent

---

Did you receive it?

---

Yes, we're taking a look.

---

Just to update you we're still looking into this...