update-apt-xapian-index uses too much CPU and memory

[Denis Rut'kov]

Binary package hint: apt-xapian-index

A background silent update process shouldn't use 98% CPU. It makes system sluggish with no visible reason.

[Tormod Volden (tormodvolden)]

On my old laptop, the CPU usage is not too bad (5%) but it uses insane amounts of memory, ca 100 MB. Most annoying thing since the dreaded scrollkeeper-update.

[Gonzo (alex-satellite)]

I confirm that too. It uses 98% CPU but for a relatively short period of time.

[Vincenzo Ciancia (vincenzo-ml)]

It uses all the available cpu and interrputs the work of people for no reason. Would someone kindly assign a priority to this bug?

[Pelládi Gábor (pelladigabor)]

Just happened to me on an Asus EEE 901. I was copying large files from a pendrive, and after few minutes my desktop was almost frozen, unusable. The system responded for a mouse action in 30-60 seconds. The hard drive led (SSD in fact) was continuously on. I managed to switch to vt1 and log in (it took a minute), and ran top. It showed that update-apt-xapi was using 100% CPU. After about 8-10 minutes of struggling, the process finished it's mysterious work, and the system was back to normal again. But rendering the box unusable for minutes can be frustrating. At least can somebody tell me why we need this background process at all? Can I uninstall it, without breaking functionality?

[Vincenzo Ciancia (vincenzo-ml)]

Il giorno gio, 28/05/2009 alle 19.06 +0000, Pelládi Gábor ha scritto:
> At least
> can somebody tell me why we need this background process at all? Can I
> uninstall it, without breaking functionality?

The program is described in apt-cache show as supporting the index of
packages that you see when you use "add/remove" from the applications
menu in the gnome panel. I uninstalled it and nothing bad happened (I
use synaptic or apt to install/uninstall applications).

[David Taylor (me-davidandrewtaylor)]

"At least can somebody tell me why we need this background process at all"

I think it trawls through the titles and descriptions of your apt database of packages making it possible for you to search for packages not just for their title but also by their description. However I think in the past I have been able to search by package descriptions long before this process was crippling my PC.

Anyway my solution is a little less dramatic than uninstalling the thing (if its existence is necessary I don't know, I doubt it but have kept it in case). I just went into the directory /etc/cron.weekly and moved the file apt-xapian-index to the folder /etc/cron.monthly. It still rears its ugly head occasionally but at just six times between releases I can live with it.

[Tanker Bob (tankerbob)]

Confirmed problem on Ubuntu 9.04 x86_64 Jaunty. I am running in Intel Core 2 Quad Q9650 CPU, and the update-apt-xapian process takes 100% of one core. As of this writing, it has run for 468:50:30 according to top with no end in sight. This is absurd.

I tried purging the package and killing the process, but then the Quick Search window in Synaptic no longer works. I tried making the /etc/cron.weekly/apt-xapian-index script non-executable, but it runs anyway.

Other than the Quick Search in Synaptic, I see no use for this process or its huge database. It either need to be fixed so that it doesn't eat 100% of a CPU core, or eliminated as a requirement for Synaptic's Quick Search so that it can be removed from the distribution.

[Tanker Bob (tankerbob)]

I just killed the process I wrote about this afternoon. In checking the database, I noticed that it was last written over 2.5 hours ago. Yet, the update-apt-xapian process was still taking 100% of one CPU core until I just killed it. I took David's advice and moved the executing script from /etc/cron.weekly to /etc/cron.monthly. This needs to be fixed.

[jpangamarca (jpangamarca)]

It eats up a very high percentage of memory on my machine. See attachment. I removed the package, seems like it's not very useful anyway.

[JeffB (n35cwii9)]

I have an old 866Mhz machine with 256MB RAM.
Top only shows this process consuming around 40% of the CPU.
However, this process brings my machine to its knees.
The mouse doesn't move well. Menus take forever to pop-up.
Programs won't close without the warning "Application is not responding".
I think perhaps I am out of RAM and thus thrashing the cache.

I don't know how the kernel handles a background task wanting all available memory, thus leaving none for the application in focus.

It takes around 10 to 20 minutes to complete running on my machine.

I am running Ubuntu 8.10

[Launchpad Janitor (janitor)]

This bug was fixed in the package apt-xapian-index - 0.21ubuntu2

---------------
apt-xapian-index (0.21ubuntu2) karmic; urgency=low

  * run the weekly update with nice and ionice (LP: #363695)

 -- Michael Vogt <email address hidden> Tue, 14 Jul 2009 09:22:34 +0200

[Michael Vogt (mvo)]

I made it run with nice and ionice now. That should make it somewhat less problematic. I'm testing the memory behavior now in a virtual machine with little resources to see what can be done here.

[Tormod Volden (tormodvolden)]

> I made it run with nice and ionice now.

That sounds like a band-aid solution. This must be broken either in code or concept if it consumes so much resources. Why doesn't each package installation add itself to a database, instead of having an indexing monster run regularly even if no new packages are installed?

[Tanker Bob (tankerbob)]

Is the "fix" committed just in Karmic? It needs to be fixed in other releases since that's where we all encountered it.

[Kristopher Ives (krisives)]

Any changes I made to the status of this bug where accidental. Currently update-apt-xapian-index is running and was making my system extremely sluggish with lots of IOWait, and my mouse clicked the Fix Released button on accident.

[Kristopher Ives (krisives)]

Considering the Add/Remove programs doesn't have much of a "live search" feel to it (when I search for packages it doesn't update for a few seconds and takes a lot of CPU) I don't see what this index is accomplishing.

As someone already mentioned, why can't this just be a done at package install/removal time? The prelink package does this. People expect the system to be under heavy usage while doing package management, but a daemon either needs to be unobtrusive and quick.

Also from a scalability point of view I imagine that this daemon redundantly touches a lot of packages that haven't changed, since it's execution time seems to (understandably) grow with the amount of packages I have installed. A post-install solution would cut down on the overall time wasted creating this index.

[Olafur Arason (olafura)]

This is still a problem with:
0.21ubuntu2

Firefox and tracker are bad enough but this is ridicules.

[Jasmine Hassan (jasmine-aura)]

Confirming #18 Olafur Arason's experience..

On Karmic, with apt-xapian-index-0.21ubuntu2

Agreed with #14 Tormod Volden, and I really wish it was even a band-aid solution.

Test-bed:
Pentium-III 500Mhz with 192MB RAM running a minimal install and a light-weight LXDE/openbox desktop, idle, with only 48MB of the 192MB physical RAM being used.

Result: update-apt-xapian-index consumes 92-98% CPU, and over 37.5% of physical RAM.

I'm sorry, but I do not think the "run with nice and ionice" could be considered a proper fix. So if you'll kindly allow me, I'll change the bug status back to "confirmed" for now.

[NoOp (glgxg)]

85.4% CPU - Intel 2.4Ghz/1G Ram.
Jaunty 2.6.28-16-generic (Gnome)

$ apt-cache policy apt-xapian-index
apt-xapian-index:
  Installed: 0.16
  Candidate: 0.16
  Version table:
 *** 0.16 0
        500 http://archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

[Tormod Volden (tormodvolden)]

On Ubuntu 9.10, it accumulates a whole minute of CPU (observed with top), on a machine with dual-core 3GHz and 2GB RAM.

[Mirza (mirza-dervisevic)]

is this bug still present in 9.10 karmic ?

[Isak Frants (isakfrants)]

Mirza: Please read the other posts before adding comments. #21 is clearly still affected by this issue and Yes it takes waaaay too much system resources to update its index. On my AMD 3700+ it uses 100% CPU for at least 20s. (I'll monitor it the next time it runs in Karmic to get more exact time.)

Is it only Synaptic that uses this index? Does anyone know? Does Software Center use it as well? I mean, a non-geek person uses Software Center and the ultimate geek uses apt-get. This massive indexing affects all users but how many need or use this feature if it's only Synaptics Quicksearch that takes benefit from it.

The general search function in Synaptic does its job. The user types in a word, clicks enter and expects its CPU to work in order to find the target. Isn't the purpose of an indexing service to speed up the searching? It does, BUT, right now it's almost like its just MOVING the time when the CPU must work, FROM that time when the user expects it to work (when the user wants to search) TO that time when the user maybe watches a movie or playing a game? At least update-apt-xapian-index can in Karmic still bounce up while surfing the net, making the computer quite sluggish.

[Graeme Glass (graemeglass)]

Running fully updated karmic and am still affected by this. 1 core sits at 100% for minutes

[Isak Frants (isakfrants)]

Not trying to cause a "me too" storm or anything, but since I promised to mention more exactly for how long it uses my CPU I'll add yet another comment. On AMD 3700+ it uses maximum resources for 40-60s. The situation is better now than in Jaunty where it would consume resources on almost every boot while in Karmic it runs more seldom.

Still bad though when I was running Gimp, Word 2007 through Wine and Firefox that this suddenly bounces up and makes everything sluggish :S If it has to run, run when computer is not in use.

[helpdeskdan (helpdeskdan-gmail)]

Me too! ;-) Couldn't this be launched with a lower nice value?

[Rolando (rolcamus)]

update-apt-xapian-index

In my Toshiba One Core notebook uses 100% cpu for several minutes and started at any time making the machine unusable,

[MarcS (marc-schmitzer)]

I'm experiencing the same problem on a Dell Laptop.

From the update-apt-xapian-index manpage:
> -u, --update
> incremental update, reindexing only those packages whose version has changed since the last run

Sounds reasonable, but is not used in /etc/cron.weekly/apt-xapian-index.

The attached patch adds this option.

[Saulius Krasuckas (saulius2)]

MarcS, I suppose unified diff format is the standard nowadays (diff -u:)

[MarcS (marc-schmitzer)]

Oh, my bad, excuse the newbie.
It's kinda trivial anyway.

[Evan Carroll (evancarroll)]

Still present in up to date karmic Feb 3, 2010. Going to proceed with patch.

[dazza5000 (darran-kelinske)]

was experiencing this on lucid lynx alpha2

[Kristian Kißling (kkissling)]

affects my too on Lucid Lynx, alpha 2 with all updates, running as guest in virtual box

[William Shand (williamshand14)]

Affects me too, starting to get rather annoying :(

[Dave Martin (dave-martin-arm)]

I've been experiencing this at least since Karmic. On armel especially, it can sometimes cause sluggish performance for a few minutes after boot.

[jonobe (jonolewis)]

I have just switched to Kubuntu 9.10 from the Ubuntu Gnome distros, only to find it is all locked up until I kill this xapi process. It's pretty serious - completely locking up my computer for ages (until I kill it!).
I am amazed reading these comments it has been around so long and still hasn't been dealt with. I'm a bit annoyed because i finally persuaded my Dad (a fervent Windows man) to give Linux a go and gave him the Kubuntu disc I'd just written. D'oh.

Why do I think he's actually going to love this?

[FrozenFire (frozenfire-thefrozenfire)]

I too am plagued by this bug. My system locks up and my fans start spinning full-powered when this process runs. Perhaps defaulting it to a lower-priority nice level would remedy the issue?

[Tamás Kiss (tkiss80)]

In Jaunty, I found an interesting piece of code in /etc/cron.daily/mlocate. It checks if the laptop is on AC power, and if not, it exits without updating the locate database. I know this is not closely related to this bug, but apt-xapian-index doesn't seem to have this check. Maybe someone who has a laptop should run some tests to see if it worth putting into the script and could file a bug report if necessary. (I've never had a laptop, so I can't experiment with it).

[jferguson (jferg977)]

running 9.10 on a 500mHz P3 notebook, this application pretty much shuts it down for a couple of hours on saturday morning. My experience is same as others I read here. I figured out what it was, killed it and saw the disk-banging stop and got my cpu back.

If all this does is give Synaptic Package Manager quick-search a current index - at least on saturday efternoon, it has to be the silliest resident ap I've ever seen.

I'm taking it out of cron.weekly, making it available to be run manually, while I'm on vacation and seeing if that lets it do whatever it seems to be doing.

If the wise folks who watch the gates on what can get into a Linux installation would keep an eye out for stuff like this, some of use with older machines would be better served.

To think that the Linux believers think that Windows is the only system with bloatware. This is a prime example.

[vovaseagull (vovaseagull)]

Hello,

Please help, I can't get updates, it says update apt xapian index unfound

[Hannibal (hannibal-wurst)]

Affects me too, update-apt-xabian is using one core at 100% for a minute everyday.

Version:
apt-xapian-index 0.25ubuntu2

System:
Distributor ID: Ubuntu
Description: Ubuntu 10.04.4 LTS
Release: 10.04
Codename: lucid

Kernel:
2.6.32-45-generic x86_64

CPU:
Intel(R) Core(TM)2 Duo CPU U9400 @ 1.40GHz

If any more information are needed, I'd be happy to provide them.

[Artem (artem4)]

The same problem on the old PC.
On modern PCs do not encounter this problem.

Lubuntu 12.10 - x86
Intel Celeron 1.7Ghz
768 RAM

update-apt-xapian-index
loads of 100% CPU

Help please!

[itsjustarumour (itsjustarumour-gmail-deactivatedaccount-deactivatedaccount)]

Still a problem on 12.10 (64 bit) - all 4 CPU cores maxed out and hard disk being totally thrashed for several minutes every time I boot up and the desktop loads.

[Dimitrios Symeonidis (azimout)]

Bug is still there, Ubuntu 12.04.1 server 32bit, running on an old laptop. Process gets started but the daily apt cron job, and after a while it gets killed for running out of memory.

[Max Polk (maxpolk)]

A weekly fatal unable to fork error message from /etc/cron.weekly/apt-xapian-index on a server with 512MB memory with a web server and database server running leads to this bug. That cron job calls /usr/sbin/update-apt-xapian-index, which is a Python script that imports axi and axi.indexer.

Sorting is a classic computer science problem with both time and space complexity. For time think CPU. For space think memory.

The solution is to change the sorting algorithm in the python axi and axi.indexer modules. The first priority is to switch to an algorithm that consumes a whole lot less memory (i.e., each step of the algorithm keeps less objects in memory), and it will stop crashing and stop thrashing (memory swapping to disk).

The second priority is of lesser importance (because renice can solve a lot of the effect), which is to switch to an algorithm that takes a lot less time to run (i.e., takes fewer steps to complete), and it will stop consuming so much CPU for so long.

[Max Polk (maxpolk)]

On an idle system with 512M memory and 768M swap, while /etc/cron.weekly/apt-xapian-index was running, I used free to see memory and swap used. It rose to then peaked at this:

             total used free
Mem: 503528 497736 5792
Swap: 786428 231196 555232

Total used memory is 728M.

After ending, it immediately dropped back to this:

             total used free
Mem: 503528 259160 244368
Swap: 786428 224484 561944

Total used memory is 483M.

I conclude that apt-xapian-index consumes the difference, which is 245M.

Running "apt-cache stats" I see at the end "Total space accounted for: 26.0 M".

Therefore, it takes 245M to sort and index 26M of information. This seems conclusive that the algorithms, containers, and functions chosen are very inefficient. It should definitely not require 10 times the memory space of what is being indexed.

[Max Polk (maxpolk)]

I added my above comments to bug 655831

[Julien Olivier (julo)]

I just stumbled on this bug today in raring. So, I confirm that the bug is still not fixed.

[Muhammad Yunus Ahmad Mazuki (hiragana9821)]

Yup, this exists in 13.04 all right.

[Germán Bobr (gbobr)]

I can confirm this bug is still affecting Ubuntu 12.04 LTS

[Paul Buonopane (zenexer)]

Encountered this on a fresh instance of raring immediately after installing and updating apt-file. sudo apt-file purge immediately fixed the issue.

[Karim Rekik (wkrekik)]

Bug encoutered in 14.04 (dev branch) also.

[Braiam Peguero (braiampe)]

Please, fill new bug reports if you still find this issue. The usage is *by-design*. It was designed to not hog the CPU.

[Serhiy (xintx-ua)]

> "The usage is *by-design*. It was designed to not hog the CPU."
> "update-apt-xapian-index uses too much CPU"
I'm lost in these arguments.

[John Mullen (jmullentech)]

Bralam's comment is irrelevant.

I just encountered the problem with LUbuntu 13.10 32-bit, after installing "Ubuntu Software Center". I then replicated on Ubuntu 13.10 32-bit.

System stats once "update-apt-xapian-index" begins: 99% CPU usage on FOUR CORES with 257MB of memory used by the process which renders the system completely unusable.

I'm seriously tempted to just re-write the entire program and push it all upstream for the sake of the community. This is RIDICULOUS! FIVE YEARS after the bug was noted and there is NO fix outside of simply *not using it*.

You're driving people away from Ubuntu by not fixing this.

[Paul Nicholson (paul-v)]

My 12.04.5 LTS occasionally grinds to a halt with login nearly impossible. Finally I caught this remote embedded 256Mbyte system in the act and found update-apt-xapi had driven the machine well into swap. Hopefully apt-get remove apt-xapian-index will prevent this happening again until this long-standing defect is fixed. Perhaps mmap its big RAM data to /tmp/something and put in a substantial sleep in its main loop.

[Miro Janosik (miro-janosik-geo)]

Reproduced on daily build of XUbuntu 15.04 kernel 3.19.0-12-generic

[Carl Englund (englundc)]

This happened to me today on XUbuntu 15.04 final with updates. It seems to stay on hogging as much as CPU as it can get its hands on (nice 10 apparently) and using about as much memory as stated earlier here. It just keeps on hogging, making me wonder if something's gone wrong.

I probably can figure out how to disable it somewhere..an average user would not.

[Removed by request (removed4606406)]

Why not just limit this to 20% maximum of 1 core and 5% of memory? (14.04.2 LTS here). no one would even otice this any more.

[fyo (fyo)]

The suggested fix and the currently applied fix differ in one important aspect: The --update option has been dropped.

tldr: Unless --update is broken (and it doesn't appear to be), it should be included in the fix as it reduces run time quite significantly.

To estimate the effect of --update I tried installing a number of small apps (e.g. htop) and running the command: update-apt-xapian-index --update (with default niceness). The time required to perform this update varied from about 40 seconds to almost 3 times that. The update process appears to be split into three main components:

- Reading translations for all ubuntu repos in use (security_universe, updates_restricted, main, universe, partner, multiverse, etc).
- Reading xapian index.
- Updating xapian index.

When a complete rebuild is performed, the index doesn't need to be read (and isn't).

In terms of time, the first and second steps are fairly constant, while the updating bit varies wildly with no pattern I was able to determine (from about 10 to 60 seconds).

Reading the index was quick, about 5 seconds.

The translations part, which I assume is basically fetching complete descriptions of all packages installed, is rather slow even on a fast internet connection. On my system, it took a consistent 25 seconds.

Without debating the merits of the index and its use, there are certainly a number of optimizations that could be made. Even without touching the process itself, just using the incremental update feature cuts run time significantly with no apparent downside.

[fyo (fyo)]

This bug has been fixed upstream as of April 2010, but for some reason NOT in any of the Ubuntu packages since.

upstream:
http://anonscm.debian.org/cgit/collab-maint/apt-xapian-index.git/tree/debian/cron.weekly

ubuntu:
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/apt-xapian-index/wily/view/head:/debian/cron.weekly

This was done deliberately, so the bug should be modified to WONT FIX.

Agree or disagree, you can see the reason for the WONT FIX here:
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/apt-xapian-index/wily/revision/22

(One might argue that Software Center should handle the database being updated more gracefully. If anyone feels sufficiently strongly that way, I would recommend opening a bug on Software Center.)

[Saulius Krasuckas (saulius2)]

* 2016-03-31 10:12 GMT+03:00 fyo wrote:
>
> Agree or disagree, you can see the reason for the WONT FIX here:
> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/apt-xapian-index/wily/revision/22

fyo, do you mean this statement:

> - do not modify the DB "in-place" with --update to avoid
> software-center seeing a corrupted database when it has
> it open at the same time

?

S.

[fyo (fyo)]

> fyo, do you mean this statement:

> > - do not modify the DB "in-place" with --update to avoid
> > software-center seeing a corrupted database when it has
> > it open at the same time

Yes, that appears to be the argument for removing --update, which was otherwise added in an upstream patch.

It is unfortunate that update-apt-xapian-index resource use is increased many-fold due to Software Center not (gracefully) handling an in-progress update. Depending on the nature of the Software Center issue, this choice is perhaps understandable.

I should note that I was NOT able to reproduce any issue with Software Center while running update-apt-xapian-index --update. The closest thing I could get was a 10 second "animated loading ring" coinciding with the update process being at 99% (any io heavy activity could probably give that result, though).

[Saulius Krasuckas (saulius2)]

* 2016-04-02 23:43 GMT+03:00 fyo wrote:
>
>> fyo, do you mean this statement:
>
>> > - do not modify the DB "in-place" with --update to avoid
>> > software-center seeing a corrupted database when it has
>> > it open at the same time
>
> Yes, that appears to be the argument for removing --update, which was
> otherwise added in an upstream patch.

I still fail to see how removing ionice binary (a disk I/O scheduler)
from the index rebuilding can possibly change DB modification type
from "in-place" to some other type:

--- quote ---
 then
         if [ -x "$IONICE" ]
         then
- nice -n 19 $IONICE -c 3 $CMD --update --quiet
+ nice -n 19 $IONICE -c 3 $CMD --quiet
         else
- nice -n 19 $CMD --update --quiet
+ nice -n 19 $CMD --quiet
         fi
 fi
--- quote ---

Have I missed something inbetween? This comment seems absolutely
irrelevant to me, to say the least. Maybe we need to contact Michael
Vogt to make the things clear?

> I should note that I was NOT able to reproduce any issue with Software
> Center while running update-apt-xapian-index --update. The closest
> thing I could get was a 10 second "animated loading ring" coinciding
> with the update process being at 99% (any io heavy activity could
> probably give that result, though).

That could prove the comment from Changelog is unrelated.

> It is unfortunate that update-apt-xapian-index resource use is increased
> many-fold due to Software Center not (gracefully) handling an in-
> progress update. Depending on the nature of the Software Center issue,
> this choice is perhaps understandable.

OK, I am not into design of this exact software solution, but if your
first statement is true then it's the design itself which is most
flawed here. IMHO, Software Centrer should notify user about the
update ongoing in the background. And then use a backup of the DB.
Until the new revision of DB is finalized. After which S.C. should
switch to the latter.

This is quick shot from a guy walking by.

S.

[fyo (fyo)]

> I still fail to see how removing ionice binary (a disk I/O scheduler) from the index rebuilding can possibly change DB modification type

That's not what the diff says. There is no change in ionice behavior in this patch. The patch removes --update from both branches of the if-statement.

[Saulius Krasuckas (saulius2)]

* 2016-04-03 23:40 GMT+03:00 fyo wrote:
>
> That's not what the diff says. There is no change in ionice behavior in
> this patch. The patch removes --update from both branches of the if-
> statement.

Thanks for pinpointing that to me, fyo -- somehow I have mixed these
four lines (and --update + --quiet options) up.

S.

[Mateusz Stachowski (stachowski-mateusz)]

This is still a problem in 16.04 LTS.

This process uses 100% CPU for a long time and up to 500MB of RAM on my machine. That's completely unacceptable.

Maybe now when Ubuntu switched to GNOME Software is a good time to add the --update option to both cron.weekly and cron.daily.

[dronus (paul-geisler)]

Does anybody actually know if this is a flaw of some settings, or the xapian engine by design? There are so many database and indexing systems out there, I can't get it why this single indexing job behaves so bad since years.

[Tobias Sturm (tobstu)]

Confirming this issue with Ubuntu 14.04.3 LTS on an AWS t2.nano instance (only 512MB RAM).
The weekly cron job that is set up by default runs ~24h after machine creation and completely hogs the instance for more than 2 minutes.

IMHO: A process which is setup by default should not be so greedy.

[Chiheb Nexus (chihebnexus)]

Confirming this issue with Ubuntu 14.04.4 LTS on HP 630.
apt-xapian-index in /etc/cron.weekly uses 100% of my CPU.

[hackerb9 (hackerb9)]

Confirming that this is still a bug in Ubuntu 16.04.1 LTS (Xenial Xerus). Tested on a Pentium III Mobile 1GHz w/ 1GB ram. (Compaq Evo N600c).

Also, I note that this bug has been open for seven years and offer a workaround that solves the problem for me. Since the update-apt-xapian-index process is needlessly impolite even with nice and ionice, I wrote a script (called "stutter") that forces the process to pause repeatedly. (Technically, it uses SIGSTOP/SIGCONT with a 10% active duty cycle and 0.1s period).

It's a kludge, but it definitely works. As I'm posting this comment, I'm running update-apt-xapian-index in the background. Without my script, the streaming YouTube video I'm also playing in the background would have been unwatchably choppy instead of smooth.

To use my solution put the attached script into /usr/local/bin/stutter, make it executable, and update /etc/cron.weekly/apt-xapian-index to prepend stutter before the command:

==== /etc/cron.weekly/apt-xapian-index ====
#!/bin/sh

CMD=/usr/sbin/update-apt-xapian-index

# ionice should not be called in a virtual environment
# (similar to man-db cronjobs)
egrep -q '(envID|VxID):.*[1-9]' /proc/self/status || IONICE=/usr/bin/ionice

if [ -x "$IONICE" ]
then
    IONICE_ARGS="-c 3"
else
    IONICE=""
fi

# Check if we're on battery
if which on_ac_power >/dev/null 2>&1; then
    on_ac_power >/dev/null 2>&1
     ON_BATTERY=$?

    # Here we use "-eq 1" instead of "-ne 0" because
    # on_ac_power could also return 255, which means
    # it can't tell whether we are on AC or not. In
    # that case, run update-a-x-i nevertheless.
    [ "$ON_BATTERY" -eq 1 ] && exit 0
fi

# If we have B9's stutter utility installed, use it to
# prevent excessive interference with interactive users.
STUTTER=$(which stutter)

# Rebuild the index
if [ -x "$CMD" ]
then
    $STUTTER nice -n 19 $IONICE $IONICE_ARGS $CMD --quiet
fi

==== /usr/local/bin/stutter ====
#!/bin/bash

# stutter: Force a process to pause its work every once in a while.
# v1.0 (c) 2016 hackerb9 - GPLv3 or higher.
#
# Usage: stutter -p PID
# or: stutter command [arguments...]

# Even with the latest Linux (4.4, at the moment) it is possible for
# background processes to rudely prevent interactive use of a
# computer. This is true even with "nice -n 19 ionice -c 3 $CMD".
#
# [Yes, I'm looking at you, update-apt-xapian-index.]

# This kludge repeatedly sends STOP and CONT signals to a process to
# force it to give up the resource (CPU/disk/network) it is hogging.

# A reasonable default is to have the process active for 0.01s and
# sleep for 0.09s. (A 10% duty cycle with a period of 0.1s).
ontime=0.01
offtime=0.09

#verbose=true
debug() {
    if [ "$verbose" = "true" ]; then
 echo "$@" >&2
    fi
}

usage() {
    period=$(echo "$ontime + $offtime" | bc)
    duty=$(echo "$ontime * 100 / $period" | bc)

    cat <<EOF
stutter - Force a process to pause its work every once in a while
Usage: stutter [ -p <pid> | <cmd> ]

Current defaults
    on time: $ontime seconds
   off time: $offtime seconds
   (A $duty% duty cycle with a period of ${period}s).
EOF
}

cleanup() {
    if [ "$pid" ] && ps --pid $pid >/dev/null; then
 if [ "$processWasAlr...

[D J Gardner (djgardner)]

Assuming there's no way that u-a-x-i can be re-written to avoid using so much ram, and so much CPU, the "stutter" kludge above makes it clear that it it ought to have sleeps in it. Use of nice (should be nice -19, in my book) and ionice have reduced the problem, but the
bug should still be open.

[Stefano Forli (ntropia)]

Still happily chewing CPU cycles on 16.10.

Another pretty effective workaround might be: apt-get remove --purge apt-xapian-index

The downside (on Kubuntu) it's that it takes out also muon, but if you don't depend on it, it makes a terrific difference on your laptop battery life.

[Emanuele (emanuc)]

Kubuntu 18.04, again the problem has not been solved, sometimes I find myself the laptop or desktop that slows down, looking through the processes there is always the process "apt-xapian-index" that uses CPU.
I resolve by removing the package, but it pulls other dependencies: kubuntu-driver-manager, kubuntu-notification-helper.
I know how to solve by removing the package, but a new user who does not know how to do it could blame Kubuntu or KDE.

[Tiedemate (bjoerntiedemann)]

Th bug was reported in 2009 and in Kubuntu 18.10 the bloody thing is still making my laptop unusable for several minutes every day after boot although it's not even in cron.daily. It is super annoying.

[RONIT RAJ (ron0245)]

This bug was reported way back in 2009 . Today it's 1st June 2020 and this bug is still here kubuntu 18.04 . This background process fires up a few seconds after i turn on my laptop and continues to consume 100% of both the cores and after a minute or so when it stops . Python3 would then start consuming the CPU power , I suspect this again is something related to APT .

All of this is really annoying , during the time when this process is running you can't do anything .

[Jochen Fahrner (jofa)]

I think this bug is Ubuntu-specific. It never happend since I'm using Devuan/Debian.

[Jānis Kangarooo (kangarooo)]

What is going on? Please make last 32-bit Ubuntu Kubuntu Lubuntu Xubuntu 18.04 usable out of box for everyone who will now come with old laptops to use 32-bit version.
Remove this bad package. Who is trolling and not allowing fix implemented?
I just installed old Laptop and on each start computer is unusable for few minutes since i dont need this, also uses electricity, cpu is slow, even if i put ssd, cause its doing a lot in slow cpu for long time few minutes.