It was little Bobby Tables
this post was submitted on 12 Aug 2024
551 points (96.8% liked)
Comic Strips
12384 readers
2442 users here now
Comic Strips is a community for those who love comic stories.
The rules are simple:
- The post can be a single image, an image gallery, or a link to a specific comic hosted on another site (the author's website, for instance).
- The comic must be a complete story.
- If it is an external link, it must be to a specific story, not to the root of the site.
- You may post comics from others or your own.
- If you are posting a comic of your own, a maximum of one per week is allowed (I know, your comics are great, but this rule helps avoid spam).
- The comic can be in any language, but if it's not in English, OP must include an English translation in the post's 'body' field (note: you don't need to select a specific language when posting a comic).
- Politeness.
- Adult content is not allowed. This community aims to be fun for people of all ages.
Web of links
- [email protected]: "I use Arch btw"
- [email protected]: memes (you don't say!)
founded 1 year ago
MODERATORS
Alright who's running the database on the same machine as the server...π
If you can do this, do it. It's a huge boost to performance thanks to infinitely lower latency.
And infinitely lower reliability because you can't have failovers (well you can, but people that run everything in the same host, won't). It's fine for something non critical, but I wouldn't do it with anything that pays the bills.
I work for a company that has operated like this for 20 years. The system goes down sometimes, but we can fix it in less than an hour. At worst the users get a longer coffee break.
A single click in the software can often generate 500 SQL queries, so if you go from 0.05 ms to 1 ms latency you add half a second to clicks in the UI and that would piss our users off.
Definitely not saying this is the best way to operate at all times. But SQL has a huge problem with false dependencies between queries and API:s that make it very difficult to pipeline queries, so my experience has been that I/O-bound applications easily become extremely sensitive to latency.
Iβm going to guess quite a people here work on businesses where βsometimes breaks, but fixed in less than an hourβ isnβt good enough for reliability.
load more comments
(2 replies)
A single click in the software can often generate 500 SQL queries, so if you go from 0.05 ms to 1 ms latency you add half a second to clicks
Those queries don't all have to be executed sequentially though, do they? Usually if you have that many queries, at least some of them are completely independent of the others and thus can execute concurrently.
You don't even need threading for that, just non-blocking IO and ideally an event loop.
load more comments
(1 replies)
load more comments
(1 replies)
Most beginner selfhosters.
and most every cpanel (and every other web host panel) box on the planet.
web, ftp, database, mail, dns, and more. all on one machine.
load more comments
(1 replies)
load more comments
(2 replies)
Ok, now I need a 8 season animated show and at least 2 direct-to-TV movies of this
Best I can do is a Netflix series that gets cancelled halfway through season 2 and a fan-made animation spoof on YouTube
load more comments
(3 replies)
Fuck MySQL, all my homies hate MySQL.
Postgres is the way to go.
It was you! You killed it.
I do admit to moving the company cluster from MySQL to Postgres.
But only most of the traffic, some traces still remain, so the original MySQL still works
why?
I did two rounds of very long presentations comparing those two systems.
Personal reasons:
- SQL standard support is still very weak
- lack of WAL
- array support
- weird replication support
- utf8mb4 mess took too long to resolve
- many things started to get better only after Oracle takeover
load more comments
(1 replies)
load more comments
(2 replies)
Random guess, a php error caused Apache to log a ridiculous number of errors to /var/log and on this system that isnβt its own partition so /var filled up crashing MySQL. The user wiped /var/log to free up space.
That's not far off of something that happened to me once a few years ago. My computer suddenly started struggling one day, and I quickly figured out that my hard drive suddenly had 500 gigs or so of extra data somewhere. I had to find a tool that would let me see how much space a given folder was taking up, and eventually I found an absolutely HUMONGOUS error log file. After I cleared it out, the file rapidly filled up again when I used a program I'd been using all the time. I think it was Minecraft or something. Anyway, my duck tape solution was to just make that log file read-only, since the error in question didn't actually affect anything else.
Plot twist: it was the user
That's not even a plot twist, that's expected user behavior
All evidence point to suicide.
I hadn't realized this was a .ru domain....
Maybe it's a 'Windows' server...
Systemd. SQL is now in Systemd.
Dont spoil. That's the secret in Episode 5.
I understand none of this.....
"Among us" but for Linux nerds.
It was Java, coaxing the Linux OOM killer into doing the job
/var/log has been deleted, you say...
I think we all know what this means, don't we?
Hint
ls -ld /var/log
drwxrwxr-x 18 root syslog 4096 Aug 11 08:13 /var/log
I have no clue. Root nuked the logs? Why? OOM killer does not do that.
Well, there is only one who could have erased all traces of the SIGKILL...
And only the SIGKILLER would have had reason to do so...
load more comments
(2 replies)
That seems so obvious I think we're missing something
Whatever, we have a suspect.
Bring in GDB to do the interrogation! And perhaps also call Nice, he can play the good cop...
Forgive me my ignorance, but since Apache is running as root, couldn't PHP inherit it's permissions?
The Apache main process runs as root. When it receives a request, it spawns a child process that doesn't run as root. PHP runs as the same user as the Apache child process.
Or PHP runs in its own fastcgi like process under a different account.
It looks like the OOM killer has struck again.
This process has been murdered mysteriously.
Oracle.
Will there be a follow up?
I did it like this: π« BANG WhooOooOoopty doOoO
It was the kubelet after MySQL failed his liveness probes
It was the BOFH
It was taking away resources from the coffee cam. Had to go.
Like everytime with natives, it was a race condition cascade of table locks followed by mysql suicide caused by bad cronjob scripts implemented by the user.
load more comments
(1 replies)
Mariadb did it with the candlestick in the library.
view more: next βΊ