Liferea causes a lot of hdd activity when updating feeds

Bug #335471 reported by Andreas Brandt on 2009-02-27
112
This bug affects 18 people
Affects Status Importance Assigned to Milestone
liferea (Ubuntu)
High
Unassigned

Bug Description

Binary package hint: liferea

Description: Ubuntu jaunty (development branch)
Release: 9.04
Filesystem: ext4

liferea:
  Installed: 1.4.23-0ubuntu2
  Candidate: 1.4.23-0ubuntu2
  Version table:
 *** 1.4.23-0ubuntu2 0
        500 http://de.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

When starting Liferea it takes a long time (about 2 minutes with 400 feeds) to update feeds with a lot of hdd activity going on. Also i can hear my harddrive every time i read a unread feed which didnt happen on 8.10 (with ext3).

description: updated

I can confirm this with version 1.4.23 from the official repo and 1.4.26 and 1.5.10 from PPAs.

This is with only (about) 30 feeds. VACUUM;ing the database has no effect.

Any activity leads to a lot of disk activity. The database journal file is created, deleted and and recreated seemingly for each feed item.

Changed in liferea:
status: New → Confirmed
marijus (marijus73) wrote :

the package producing this problem seems to be libsqlite3-3.6.10-1...
downgrading to libsqlite3-3.5.9-6 solved the problem for me...

it has some dependency problems though in jaunty...

So bug 333718 is a duplicate of this one.

I meant bug 337196 ! Oops !

Same here: jaunty beta, liferea 1.4.26-0ubuntu1, libsqlite3-0 3.6.10-1.
Opening an unread item takes a lot of time and hdd activity.

UnSandpiper (aybora) wrote :

Jaunty beta, ext4, liferea 1.4.26-0ubuntu1, libsqlite3-0 3.6.10-1 here.

The time to preview an item seems also to be dependent on the feed.
E.g. previewing an unread Engadget item ~3 sec vs. slashdot ~1 sec
Both contain 75 items.

Sergey Sergin (ssergin) wrote :

Ubuntu 9.04 Jaunty beta, XFS on 28.5 GB partition, liferea 1.4.26-0ubuntu1, libsqlite3-0 3.6.10-1.

Any operation takes a lot of time and courses high disc activity. To be correct I've make some tests.

The first launch took about 2 minutes and was accompanied by the unceasing work of the disc.

Console command iostat /dev/sda4 -k 60 reports
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda4 82,78 0,00 444,52 0 26671
sda4 64,86 0,00 334,26 0 20052

The second act was the import of some 200 or 300 channels and re-monitoring disk activity. This operation has already won at least 7 minutes.

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda4 91,65 0,00 453,02 0 27181
sda4 93,00 0,00 467,46 0 28047
sda4 90,85 0,00 456,54 0 27392
sda4 93,87 0,00 460,59 0 27640
sda4 93,43 0,20 457,28 12 27427
sda4 97,22 0,00 474,94 0 28501

If this is not an attempt to kill my old hard drive, what is it? :)))

In another console was running the utility inotifywait -r -m $HOME that throughout the test show this message in a circle.

/home/sergey/ OPEN,ISDIR .liferea_1.4
/home/sergey/.liferea_1.4/ OPEN,ISDIR
/home/sergey/.liferea_1.4/ MODIFY liferea.db-journal
/home/sergey/ CLOSE_NOWRITE,CLOSE,ISDIR .liferea_1.4
/home/sergey/.liferea_1.4/ CLOSE_NOWRITE,CLOSE,ISDIR
/home/sergey/.liferea_1.4/ MODIFY liferea.db-journal
/home/sergey/.liferea_1.4/ MODIFY liferea.db
/home/sergey/.liferea_1.4/ CLOSE_WRITE,CLOSE liferea.db-journal
/home/sergey/.liferea_1.4/ DELETE liferea.db-journal
/home/sergey/.liferea_1.4/ ACCESS liferea.db
/home/sergey/.liferea_1.4/ CREATE liferea.db-journal
/home/sergey/.liferea_1.4/ OPEN liferea.db-journal
/home/sergey/ OPEN,ISDIR .liferea_1.4
/home/sergey/.liferea_1.4/ OPEN,ISDIR
/home/sergey/.liferea_1.4/ MODIFY liferea.db-journal
/home/sergey/ CLOSE_NOWRITE,CLOSE,ISDIR .liferea_1.4

And so hundreds of times in a row.

Dimitrios Symeonidis (azimout) wrote :

importance=high, however I cannot reproduce this...

Changed in liferea (Ubuntu):
importance: Undecided → High
Jos Herni (jos-digiplace) wrote :

Same problems on my amd64 computer, Jaunty Beta, ext4 filesystem. Removed the .liferea_1.4 but the fresh one has the same problems.

Jos Herni wrote:
> Same problems on my amd64 computer, Jaunty Beta, ext4 filesystem.
> Removed the .liferea_1.4 but the fresh one has the same problems.

1.4.x has serious performance issues. We have solved a few with 1.5.x (soon to
be 1.6.x), and will tackle the rest upstream for 1.7/1.8

I'm also using ext4 and amd64. Liferea is now incredibly slow... it takes minutes to complete any action. It's practically unusable.

I've found that upgrading libsqlite3-0 to version 3.6.13 gives a minor performance increase, but the issue persists. The only solution is downgrading to libsqlite3-0 version 3.6.9-6, but then apt complains about broken dependencies.

The same version of Liferea (1.4.26) in Intrepid has no issues, everything is done in less than a second. The issue happens only in Jaunty, and so far, the libsqlite3-0 changes are the only thing that have either fixed it, or made any improvement at all.

abhiroopb (abhiroopb241088) wrote :

I can confirm that I am having this same issue.

Liferea: 1.4.26
Jaunty
Libsqlite 3.6.10

Laptop Specs: HP dv5242ea | Ubuntu 8.10 | Core Duo T2050 1.60GHz | 2048 MB RAM | 320GB SATA | DVD-RAM Matshita UJ 840S | nVidia G72M [GeForce Go 7400] 256mb | Intel PRO/Wireless 3945ABG

abhiroopb (abhiroopb241088) wrote :

Are there any updates for this?

kkk (kknull0) wrote :

same problem
ubuntu 9.04, ext4 amd64

Kango_V (djb-bell) wrote :

I can also confirm this. 9.04, ext4 amd64.

Pavel Logvinov (paul-mail) wrote :

Same problem. 9.04, amd64, ext4

Christophe Dumez (hydr0g3n) wrote :

Disabling barriers on my ext4 partition seems to help.

in /etc/fstab:
UUID=9b920777-5aca-40f8-afa5-631a04057401 / ext4 defaults,noatime,nodiratime,barrier=0 1 1
UUID=27941cae-e541-407e-9572-f0adc25ba175 /home ext4 defaults,noatime,nodiratime,barrier=0 1 2

I added "barrier=0" as option and rebooted.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers