The point of a good error page is to apologize for the error, to explain what happened in simple terms, which could be responsible for that, and what next steps to take.
500 error rarely provides a good explanation, so the error page should be vague. This results in users starting to refresh the page, hoping that the rendering will be miraculous, even if there is a lot of code deployment. Therefore, you must prevent such behavior by giving clear instructions on the next step.
Tell your visitors, "The site is dead.You should give up", is not a good practice. Users must have a sense of control and involvement in the situation. Give them the opportunity to send a message to the engineering team, regardless of size. Then, once the site is backed up, send them an e-mail (even generic) thanking for reporting the error and notifying the resurrection.
The best sample I have found so far is Goodbye, old page 500 on Think Vitamin (web.archive.org). You can also see examples of error pages in NetTuts + (one and two) and Smashing Magazine (one). Look in the page for
500 in each of them as they are in several places.