no, not only did the database pass away, file-info also died despite having nothing to do with the database at all.
the reason here was our provider strozzo updating their crappy virtuozzo-hosts, which cutted for some crazy reason the balls of our perl-core.
no more perl-modules left.
no more file-info there, for this relies in parts on Phil Harveys Image::Exifinfo, a really great piece of software.
thanks to an anonymous comment moaning about the nunfunctional file-info. the perl-modules are reinstalled, file-info is working again as it did.
tom
Thursday, August 07, 2008
Monday, August 04, 2008
murphys law
some might have noticed: serversniffs half dead since 72 hours.
the ups failed, power failed and the raid got corrupt. time to restore from a db-dump.
and time to upgrade: our postgresql-database did run on windows 2000, which is rather fine unless your database won't grow to bloated. postgresql won't eat more than ~ 6o0MB Shared Memory on windows 2000, wich is fine, unless your database wont grow to bloated... - because the vacuum-process needs more RAM. So I ended up with an ever increasingly fragmented database.
time to switch to linux. i tried to build the system as guest on VMWare ESXi - which i was able to manage - but there must have been something horribly wrong with the filesystem: all disk-transfers were slow as hell, usually below 10MByte/s. After 60 hours of setting up ESXi, a Linux-Guest and the database i threw the stuff away and started all over installing plain Linux Sunday evening, 48 hours after the database initially crashed.
Since then i installed linux on the machine, prepared raid-array, database and everything else. currently the data is restored from a dump and the indexes are generated - 6 of ~20 are already done, the rest might be finished by tomorrow. to what i see right now the database is considerably faster using linux and 1 GB of Shared RAM.
I apologize for the downtime, especially to the folks at blackhat.
tom
the ups failed, power failed and the raid got corrupt. time to restore from a db-dump.
and time to upgrade: our postgresql-database did run on windows 2000, which is rather fine unless your database won't grow to bloated. postgresql won't eat more than ~ 6o0MB Shared Memory on windows 2000, wich is fine, unless your database wont grow to bloated... - because the vacuum-process needs more RAM. So I ended up with an ever increasingly fragmented database.
time to switch to linux. i tried to build the system as guest on VMWare ESXi - which i was able to manage - but there must have been something horribly wrong with the filesystem: all disk-transfers were slow as hell, usually below 10MByte/s. After 60 hours of setting up ESXi, a Linux-Guest and the database i threw the stuff away and started all over installing plain Linux Sunday evening, 48 hours after the database initially crashed.
Since then i installed linux on the machine, prepared raid-array, database and everything else. currently the data is restored from a dump and the indexes are generated - 6 of ~20 are already done, the rest might be finished by tomorrow. to what i see right now the database is considerably faster using linux and 1 GB of Shared RAM.
I apologize for the downtime, especially to the folks at blackhat.
tom
Subscribe to:
Posts (Atom)