I would start by confirming or rejecting your gut feel about speed. Do you still also have your old Slackware 11 installation? If so I would start by testing raw disk read performance with:

The above command will read 64GB of data from the beginning of your disk. If you want to test your entire disk you can remove the count argument:

But reading data will take a lot of time. If you have a lot of RAM (48 GB or more) you might want to read more than 64GB to avoid cache effects. As the command has to be run as root you will have to be very careful to not make a typo. The command dd is very powerful and can easily wipe your entire installation if something is typed wrong. This might be a good day to consider your backup strategy.

Once you have compared the output on Slackware 11 and 15 you will be able to say something like:
"The raw disk read performance is almost identical on Slackware 11 and Slackware 15"
or
"The raw disk read performance is about 5 times as fast on Slackware 11 compared to 15".

If the problem is with raw disk performance you should check things like modes with hdparm.

If raw disk performance is close to identical the next step will be to compare file system performance. That can be done by creating a big file by copying from /dev/zero. To avoid things getting mixed up I will not show that command until we know about your raw disk performance.

regards Henrik

I got around to trying this just now.

Turned off all mitigations with mitigations=off, and to just be extra sure, forced mds=off and nospectre_v1 and nospectre_v2.

Bulk insert in postgresql is still abysmally slow with all kernel mitigations off, so i rebooted with all of them enabled.


On a side note, the vulnerabilities and mitigations thing is interesting, need to read up on that after being on kernel 2.6.31 for 14+ years.

On my HP laptop with the 1.6 GHz Pentium dual core and which predates the Asus by a year, i decided to try ext4 for the root partition.

It appears to boot up faster than the newer Asus with the faster CPU and hard drive. It still experiences the same slow postgresql performance though.

I do have backups of the old Slack 11.0 partitions, but i'm not willing to be backing up the new 15.0 partitions and restoring the 11.0 ones, and restoring the 15.0 ones again. The process takes too long and i'm backlogged with work. :-|

I have one other machine with Slack 11.0, but it's a modern desktop machine and really not a valid comparison.

I have been looking into hdparm options, because i thought it could be that the drives aren't running at full speed by some quirk, but they appear to be running at their top mode, which is UDMA6. Multcount is at max, 32-bit I/O, etc.

I've tweaked the kernel SATA and AHCI settings too, because i thought that maybe the kernel was falling back to a compatibility/legacy ATA mode, but no, it appears AHCI is in use.

Does it load faster if the DB is stored on USB drive?
Or perhaps, if you'd mount /tmp as tmpfs and temporarily put the DB there, does it still load slow?
Just to make it clear if it's related to FS, the drive, the kernel, or memory degradation..
Because it could be many things, all I've seen is that your DB is loading slow and that you assume it's Slackware regression.

I tested using a ramdisk with tmpfs and didn't play around with the size, and ran promptly ran out of memory. I'll give this another try. USB disk, i'll also give this a try next.

I think i can rule out the filesystem, unless ext3 mode in the ext4 driver has some serious performance regressions.

Same for the hard drive, as it uses the exact same partition layout. I DO however think about the physical placement of the files on the disk, and wonder if that could cause the slowness. Maybe the files were fragmented and/or scattered?

I don't understand what you meant by memory degradation.

For the meantime i'm just using the SQL transaction "trick" i learned. It's still nowhere near as fast as it was previously though.

Would upgrading PostgreSQL be possible? v8.3.5 is from 2008. SBo has v14.2 from 2022 available.

I use mariadb on websites and have no experience with postgresql so far.

RAM can degrade, corrode, melt, etc. There's memtest on DVD, if you suspect RAM trouble.
But if I had to guess what's going on: it's probably the DB, I'd generate a new DB and see if it's the same.

Yea that's another thing i want to try next. I was going to try it early on, and that's when i learned Slackware has never ever had postgresql.

I tried recompiling 8.3.5, because i thought it might also be a userland issue, but no improvement there.

Bumping this thread in case somebody might have some new insight into this.

For the past 7 months i've just been putting up with what appears to be really poor disk throughput on my new Slackware 15.0 install. My primary hard drive is mainly affected by this. External USB hard drives appear to have better performance. And just today, i decided to watch a DVD using an external DVD-ROM drive. The drive throughput according to gkrellm maxes out at 1 MB/s, my DVDs are unwatchable. The video player i'm using is xine. CPU usage is low.

I don't know what else i could possibly check. I've compiled and recompiled the kernel. The cpufreq governor is set to "conservative", but even "performance" does nothing, only makes the CPU run hotter.

I'm thinking of downgrading the kernel to the version that i used the longest on this machine, 2.6.31. Will this work on such a new distribution?

you can just boot a live cd and test your box.

I have seen an issue before where an internal sata disk would slow down, but an external usb disk ran full speed on an old machine. The reason ended up being that the internal sata bus was powered by the internal power supply that was developing a problem, and the usb drive was powered separately, so it was unaffected. I would check your /var/log/messages where it prints out the sata link speed established and make sure you are getting the full speed (you know 3/6 Gbps whatever your sata speed is, similarly for UDMA) or if you are getting messages about the bus getting reset after errors and configured to a slower speed to try to fix the problem.

You can try an older kernel, but I wouldn't go older than the minimum version that glibc was compiled with. It looks like slackware 15.0 will require a minimum of 2.6.32, but that is just one rule. There might be some userspace program, like one required during boot that also might break. But I guess it wouldn't hurt just to try whatever you had last working. I know that slackware 15.0 will still work with the 4.4.x series from slackware 14.2. You have older hardware, so your drivers would be expected to still work.

Thanks for the reply.

I just checked /var/log/messages. ata1 is running at full speed of 1.5 Gbps.

Do you think this could be related to the kernel build? For example, missing a driver or a config option that ended up causing things to run at a lower speed? Recently i found out that i forgot to include the ATA SFF chipset drivers when i needed to use the built-in CD-ROM and it wouldn't work, and i saw that ATA SFF included support for ICH8 SATA. Excitedly i recompiled the kernel with the ATA SFF drivers, hoping that things would go back to normal, but nothing. Alternatively, could i have included a driver or config option that's somehow causing conflicts and causing the lower speed?

ADD: I grabbed the installers for kernel 2.6.37.6 from Slack 13.37. I'm having trouble compiling 2.6.39 on my stock gcc.


ADD: Well shit. I got the "FATAL: kernel too old" panic when i booted up 2.6.37.6.

could you post output with

I'm running kernel 4.14.295 currently on Slack15. I have better results with vmware with that than 5.x.x kernels. And in general.

It's a Long Term Support until January 2024.

Compiled from source.

1 members found this post helpful.