V0.2.7 very slow

#1

I had a received going for a while, downloading from Galaxy. I was reporting as one of the online receivers in the status page, and all looked good.

Pi based DIY receiver, by the way.

I was happily downloading articles, which I accepted into my library. I have an 8G memory card, and had downloaded 3-4 G of files. The more files I downloaded, the slower the receiver gets.

It is now virtually unusable, ans there is a good 60 ro 120 seconds delay when switching between screens like setup and files. If I switch to the library, I was able to click on a few articles and they seemed to come up fairly quickly. I did not try to do any library searching, as the delay between screens is too painful.

I have the application log and system log ready to go, if you need to look at them. I di dnot want to paste them here.

I could also upload the entire contents of the memory card so you have a complete duplicate of what I have … OS, library database, etc. If you have google drive or drop box, I don’t mind uploading - would be about 5 G.

Cheers,
Brian

#2

In the last days my (diy) receiver downloaded more than 1700 files. I unzipped/installed under Librarian only small part of it. But I realized similar, as you, Brian, the reactions of the system on web interface become very slow.
I tryed the most simple but usefull system monitoring command, top, here is the part of its command line output. It was started, when I clicked on the web page, ask a submenu to display.
It seems, the librarian eat the majority of the CPU resources.
It seems me, the new, redesigned content management system behing the librarian isnot really for such a small device, as RPi.
https://wiki.outernet.is/wiki/Proposal_for_alternative_content_management_UX
My first idea was to try to install the Librarian on my desktop (i686, 3GHz CPU, debian), check the performace on it, but the first try wasnot successfull…

========================
Mem: 203716K used, 207292K free, 140K shrd, 9620K buff, 134012K cached
CPU: 84% usr 4% sys 0% nic 0% idle 0% io 0% irq 11% sirq
Load average: 1.19 0.91 0.42 2/53 299
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
220 1 root R 35996 9% 96% python -m librarian.app --conf /opt/or
285 1 root S 42616 10% 2% /usr/sbin/ondd -d --pid-file /var/run/
298 297 root R 2388 1% 0% top
291 194 root S 2184 1% 0% /usr/sbin/dropbear -w -d /opt/orx/drop
65 2 root SW 0 0% 0% [mmcqd/0]
185 1 root S 14120 3% 0% /usr/sbin/ntpd -g
46 2 root SW 0 0% 0% [kworker/0:2]
72 2 root SW 0 0% 0% [jbd2/mmcblk0p4-]
69 2 root SW< 0 0% 0% [kworker/0:1H]
90 1 root S 2716 1% 0% /sbin/udevd -d
124 1 dbus S 2440 1% 0% dbus-daemon --system
224 1 outernet S 2388 1% 0% -ash
237 224 root S 2388 1% 0% /bin/ash
297 292 root S 2388 1% 0% /bin/ash
292 291 outernet S 2388 1% 0% -ash
203 1 nobody S 2360 1% 0% /usr/sbin/dnsmasq -C /opt/orx/dnsmasq.

t.janos

#3

We’re aware of this issue. There’s a patch pending release early next week, so stay tuned.

#4

Branko,
I read with very high attention your RFC proposal about your new content management system. It has a big amount of works and it has really new approaches to manage prepacked files, use the uptodate db and indexing features. I remember the old times, before the web on the internet: it was some alternative approaches, for example the hypertext itself, the gopher system, and the database-based wais system. Finally the web was the winner, with its “native” extension of the filesystem concept in the url.
Practically the new librarian is the existing implementation of this new concept, I am very interested to see its developments.

#5

Interesting. When i was using 2.4, browsing my library was slow, and switching to it from any other tab was also slow. I put it down to the old Ubuntu netbook I was using, as browsing from a windows PC was better. I had a feeling that library browsing got slower the more full the library got. In fact, when demonstrating the system, I made sure to not have very much in the library to slow it down.

I figured that it would get fixed with subsequent releases, also didn’t mention this before!

#6

The switch that @tjanos is referring to can be found here: https://wiki.outernet.is/wiki/Proposal_for_alternative_content_management_UX

It will take some time to implement (4 weeks, I believe), but the investment will be well worth it. Feel free to start a new thread to discuss the change, if you like.

#7

This issue should be fixed by the 0.2.8 hotfix.