Bug #72789
closed
Generating PDF thumbnails can keep the CPU busy for far too long
Added by Florian Seirer almost 9 years ago.
Updated almost 9 years ago.
Description
We've migrated to a new server (RHEL7) recently, and didn't include thumbnails for the filelist module.
Now, everytime an editor clicks on a folder containing a lot of pdf files, it can take a lot of time to load the file list, because the server is still generating the thumbnails.
That alone isn't that bad, but to make matters worse, editors get impatient and click on the folder again. This creates another task that tries to generate the same (?) thumbnails.
This lead to our CPU being occupied for hours (see screenshot), until we killed the tasks manually.
Isn't there some timeout setting that should take care of this?
Files
I know this problem from a Debian Server. It's not TYPO3 related. Some PDF are able to run gostscript (gs) crazy. it's a gs bug.
My solution:
A bash script running with cron every 2 minutes. killing ps and convert on hight load, not elegant, but has proven effectiv.
#!/bin/bash
load1m=$(uptime | awk '{ print $10 }' | cut -c1-4)
threshold1m="1"
result1m=$(echo "$load1m > $threshold1m" | bc)
mailbody=$(mktemp)
if [ "$result1m" == 1 ]; then
killall convert > /dev/null
killall gs > /dev/null
msg="Load 1 min: $load1m (threshold $threshold1m)"
subject="Info: killall convert,gs 1m ($load1m) auf phsz.ch"
echo $msg > $mailbody
echo " " >> $mailbody
echo "Load average: $(uptime | cut -c55-)" >> $mailbody
echo " " >> $mailbody
echo "Time: $(date)" >> $mailbody
echo "Host: phsz.ch" >> $mailbody
mail -s "$subject" xxxx@taywa.ch < $mailbody
rm $mailbody
fi
Close this, its not a TYPO3 Bug!
Yes, we also found out that this has to do with ghostscript.
I also attached a file that causes this behaviour.
Put it in a folder, and try to open the file information popup window in the filelist module.
Or simply run "convert hygieneanleitung_plakat_3_druck.pdf test.jpg" on the command line.
And even if this is indeed a GS bug, shouldn't TYPO3 offer some kind of protection against stuck tasks like this in general?
And even if this is indeed a GS bug, shouldn't TYPO3 offer some kind of protection against stuck tasks like this in general?
I don't know if this is possible, a core dev has to answer this. I am just a typo3 integrator, and had a similar problem.
RHEL7 still uses GhostScript 9.07 at the moment.
9.16 fixes the bug, but you'd have to compile it yourself.
Still, this issue can be closed since it's not a TYPO3 problem.
- Status changed from New to Closed
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 