Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Redis crashes - a small rant about software reliability

antirez.com

Post reply on HN
Print view View original

21–30 of 112 posts

Re: Redis crashes - a small rant about software reliability

#21

Post by lucian1900 »

wheaties wrote: post #7
lucian1900 wrote: post #3

Perhaps using safer languages (and languages with better error reporting) would be a solution to these kinds of problems.

Um, no. C is a perfectly valid language and some of the best, most robust systems in the world are written in it (Linux, Git, etc.) Some languages are even built to run atop C (Cython.) Even the JVM deals with pointers, memory allocation issues, and such so you don't have to but it's still there! So using a higher level or "safer" language isn't going to stop these kinds of problems.

Putting quotes around "safer" doesn't make it any harder to make mistakes in C.

The point isn't about abstracting away the machine, but about reducing the amount of code that has no safety guarantees.

Re: Redis crashes - a small rant about software reliability

#22

Post by lucian1900 »

meaty wrote: post #4
lucian1900 wrote: post #3

Perhaps using safer languages (and languages with better error reporting) would be a solution to these kinds of problems.

Not really. We get all the same sorts of errors in our very high level C#/Asp.Net/VMware deployments and it's a shit load harder to debug with all the extra baggage that a VM and hypervisor throw on top as well... A better solution to all the reliability problems is better quality hardware i.e. not X86. X86 has very few reliability features built in past ECC. If you look at UltraSparc based machines, they can predict…

I was thinking more of something like Rust, where only a small subset of your code would be poking at memory manually. Then when you do get a mysterious crash, you only need to look at the unsafe portions of your application (or perhaps at the compiler).

Re: Redis crashes - a small rant about software reliability

#23

Post by shin_lao »

minimax wrote: post #13
shin_lao wrote: post #2

This is an interesting post, especially the part about memory testing. We have a simple policy: ECC memory is required to run our software in production. Failure to do so voids the warranty.

What if your customers want to run on EC2 instances?

On production servers using virtual machines to run our software is not advised.

Nevertheless, we would do our best to please a customer looking to host our software on an EC2 cluster, with the appropriate warnings. ;)

A bit of context: we sell a "real time" non-relational database (http://www.quasardb.net/). Our customers come to us for speed and reliability and therefore build dedicated farms to host our database.

Re: Redis crashes - a small rant about software reliability

#24

Post by jrmg »

pilgrim689 wrote: post #12
lucian1900 wrote: post #3

Perhaps using safer languages (and languages with better error reporting) would be a solution to these kinds of problems.

I'm not sure why you are being downvoted, as it is still an open question whether or not safer languages make it easier to write safer programs. So your comment may be a valid one.

They're being downvoted because they're wrong - the stuff talked about here will affect any kind of program at the machine level.

Having said that, I wouldn't downvote. The question is sparking a clarifying conversation so it's arguably worthwhile even though the premise if wrong.

Re: Redis crashes - a small rant about software reliability

#26

Post by shin_lao »

lucian1900 wrote: post #22
meaty wrote: post #4

Earlier quoted context omitted.

Not really. We get all the same sorts of errors in our very high level C#/Asp.Net/VMware deployments and it's a shit load harder to debug with all the extra baggage that a VM and hypervisor throw on top as well... A better solution to all the reliability problems is better quality hardware i.e. not X86. X86 has very few reliability features built in past ECC. If you look at UltraSparc based machines, they can predict…

I was thinking more of something like Rust, where only a small subset of your code would be poking at memory manually. Then when you do get a mysterious crash, you only need to look at the unsafe portions of your application (or perhaps at the compiler).

Rust isn't production ready.

Re: Redis crashes - a small rant about software reliability

#28

Post by jt2190 »

lucian1900 wrote: post #3

Perhaps using safer languages (and languages with better error reporting) would be a solution to these kinds of problems.

(Forgive me if I've got some technical details wrong and I'm not a C programmer, but I do feel like this is a valid question and isn't trying to tweak the noses of C programmers. C programmers please feel free to add/correct anything I'm missing.)

C has a powerful/unsafe feature in that it allows you to directly address memory and read and write data. From a high-level, there are potential problems that can happen when doing this: (1) You might overwrite data in a memory location that you were using for something else or (2) you can write data that, say, represents a string and then read it back and try to interpret it as data that represents a number.

You can easily avoid the above two problems by using a library, while still having the option to optimize the code if the need arises. Since a product like Redis needs to be very performant in both speed and memory usage, the option to optimize code can't be emphasized enough: It is a critical feature of Redis and thus C is an excellent language to use for it's development.

Re: Redis crashes - a small rant about software reliability

#29

Post by lucian1900 »

shin_lao wrote: post #26
lucian1900 wrote: post #22

Earlier quoted context omitted.

I was thinking more of something like Rust, where only a small subset of your code would be poking at memory manually. Then when you do get a mysterious crash, you only need to look at the unsafe portions of your application (or perhaps at the compiler).

Rust isn't production ready.

I never claimed it was. I'm just thinking that perhaps the approach it (and Haskell, for that matter) takes is better.

Re: Redis crashes - a small rant about software reliability

#30

Post by darklajid »

antirez wrote: post #18
minimax wrote: post #13

Earlier quoted context omitted.

What if your customers want to run on EC2 instances?

It is covered in the blog post. (This is not a critique, just an hint, I understand that reading a very long blog post is time consuming).

Nope? You seem to have misread (well, or it's me of course).

You mention EC2 in your blog post, but he asked the person requiring ECC memory or voiding the product warrany what _they'd_ do if the customer wants to run on EC2.

In fact, the GP probably used the EC2 part of your blog entry to come up with the question in the first place.

Post reply on HN