Почему apt-cache такой медленный?

Question 1

После обновления до Trusty (14.04) из Saucy (13.10) все подходящие операции выполняются очень медленно. Даже те, которые не включают в себя загрузку или подключение к каким-либо серверам. Например, отображение политики apt

# time apt-cache policy 

[...]

real    0m8.951s
user    0m5.069s
sys     0m3.861s

занимает почти десять секунд! В основном странное отставание сразу после выдачи команды. И то же самое, даже если я повторю ту же команду.

В другой системе это не занимает десятой доли секунды

real    0m0.096s
user    0m0.070s
sys     0m0.023s

Другая система немного более мощная, но до обновления заметных отличий не было.

То же самое с apt-get, все, что связано с apt. Как мне найти источник этой задержки и исправить ее?

Дополнительная информация:

# cat /etc/nsswitch.conf 

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Кстати, мое понимание того, как apt-cache работает правильно? Он не устанавливает никаких сетевых подключений при запуске apt-cache policy, верно?

На случай, если я ошибаюсь и это имеет значение, вот мои источники https://gist.github.com/anonymous/02920270ff68e23fc3ec

Question 2

Откройте терминальный и первый bleachbit

sudo apt-get install bleachbit

установки Затем выполненный bleachbit как sudo:

sudo bleachbit

Затем выполняют очистку, и Вы будете видеть, что дела начинают идти намного быстрее :)

Question 3

Question 4

Это не посещенное, чтобы быть прямым ответом, но некоторой трассировкой подсказывает для выручения открытия, что продолжается.

Используя strace не было никакого connect, т.е. это не попробовало, подключают любой сервер (процесс не открыл сокета)
```
strace -c  apt-cache policy > /dev/null
```
Трассировка это, относительная синхронизация:
```
strace -r -o apt-cache.trace apt-cache policy > /dev/null
```
Видят, какой шаг занял больше времени:
```
cat apt-cache.trace | sort | tail -20
```
Просто помнят, что это - относительная синхронизация, означая, что текущий вызов показывает свое время начала относительно предыдущего. Другими словами, это - необработанное время, взял предыдущим вызовом. Затем Вы имеете, возвращаются к apt-cache.trace для знания, какой вызов был этим. Простой способ использовать grep, который дает 10 строк перед соответствием:
```
grep -B10 0.008271 apt-cache.trace
```
Однако я думаю strace, усовершенствованный инструмент, я предлагаю пробовать ioprofiler , которые обеспечивают GUI для производительности IO.
1. Установка это
```
sudo apt-get install python-matplotlib python-qt4
make profiler
sudo make install_profiler
```
2. способный кэш Трассировки
```
ioprofiler-trace apt-cache policy
```
3. Открытые результаты
```
ioprofiler ioproftrace.log
```

Question 5

По моему опыту, задержка способной операции является довольно естественной, если количество пакетов, известных Кв., очень высоко. Для знания количества пакетов работает apt-cache stats. Сделайте это и на компьютере и покажите вывод.
Рассматривают следующую ситуацию. После начальной загрузки из живой ISO (расположенный в жестком диске), способная операция такой apt-get install берет меньше, чем секунда. Количество пакетов, известных Кв., является ~7k. После добавления некоторых источников программного обеспечения, таких как пакеты от вселенной, основной Кв., знают ~50k пакеты. Теперь команда apt-get install занимает ~9 секунд (создающий дерево зависимостей и т.д.). Теперь размер кэша составляет ~60 МБ

Question 6

Я заметил, что удаление Центра программного обеспечения и скоростей передачи данных установки приложения способный кэш довольно много теперь, когда я использую синаптический диспетчер пакетов...

Question 7

Question 8

Согласно моему тестированию причины это настолько медленно, то, потому что apt-cache policy some-package выполняет итерации по дескрипторам файлов, пока это не поражает предельную ошибку.

~# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04 LTS"
~# ulimit -n 65535; time apt-cache policy snmpd
snmpd:
  Installed: 5.7.2~dfsg-8.1ubuntu3
  Candidate: 5.7.2~dfsg-8.1ubuntu3
  Version table:
 *** 5.7.2~dfsg-8.1ubuntu3 0
        100 /var/lib/dpkg/status

real    0m3.611s
user    0m0.432s
sys     0m0.264s
~# ulimit -n 100; time apt-cache policy snmpd
snmpd:
  Installed: 5.7.2~dfsg-8.1ubuntu3
  Candidate: 5.7.2~dfsg-8.1ubuntu3
  Version table:
 *** 5.7.2~dfsg-8.1ubuntu3 0
        100 /var/lib/dpkg/status

real    0m0.108s
user    0m0.011s
sys     0m0.016s

, Например, я вижу этот вид материала когда stracing процесс:

[pid 10447] fcntl(65534, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)
[pid 10447] getrlimit(RLIMIT_NOFILE, {rlim_cur=65535, rlim_max=65535}) = 0

я думаю, что это указывает на ошибку в способном кэше. Один hacky способ работать вокруг этого состоял бы в том, чтобы ограничить количество открытых файлов, но это могло вызвать вещи перестать работать излишне в некоторых случаях.

Brask · Answer 1 · 11 June 2014 в 05:53

Откройте терминальный и первый bleachbit

sudo apt-get install bleachbit

установки Затем выполненный bleachbit как sudo:

sudo bleachbit

Затем выполняют очистку, и Вы будете видеть, что дела начинают идти намного быстрее :)

user.dz · Answer 2 · 11 June 2014 в 05:53

Это не посещенное, чтобы быть прямым ответом, но некоторой трассировкой подсказывает для выручения открытия, что продолжается.

Используя strace не было никакого connect, т.е. это не попробовало, подключают любой сервер (процесс не открыл сокета)
```
strace -c  apt-cache policy > /dev/null
```
Трассировка это, относительная синхронизация:
```
strace -r -o apt-cache.trace apt-cache policy > /dev/null
```
Видят, какой шаг занял больше времени:
```
cat apt-cache.trace | sort | tail -20
```
Просто помнят, что это - относительная синхронизация, означая, что текущий вызов показывает свое время начала относительно предыдущего. Другими словами, это - необработанное время, взял предыдущим вызовом. Затем Вы имеете, возвращаются к apt-cache.trace для знания, какой вызов был этим. Простой способ использовать grep, который дает 10 строк перед соответствием:
```
grep -B10 0.008271 apt-cache.trace
```
Однако я думаю strace, усовершенствованный инструмент, я предлагаю пробовать ioprofiler , которые обеспечивают GUI для производительности IO.
1. Установка это
```
sudo apt-get install python-matplotlib python-qt4
make profiler
sudo make install_profiler
```
2. способный кэш Трассировки
```
ioprofiler-trace apt-cache policy
```
3. Открытые результаты
```
ioprofiler ioproftrace.log
```

totti · Answer 3 · 11 June 2014 в 05:53

По моему опыту, задержка способной операции является довольно естественной, если количество пакетов, известных Кв., очень высоко. Для знания количества пакетов работает apt-cache stats. Сделайте это и на компьютере и покажите вывод.
Рассматривают следующую ситуацию. После начальной загрузки из живой ISO (расположенный в жестком диске), способная операция такой apt-get install берет меньше, чем секунда. Количество пакетов, известных Кв., является ~7k. После добавления некоторых источников программного обеспечения, таких как пакеты от вселенной, основной Кв., знают ~50k пакеты. Теперь команда apt-get install занимает ~9 секунд (создающий дерево зависимостей и т.д.). Теперь размер кэша составляет ~60 МБ

TenPlus1 · Answer 4 · 11 June 2014 в 05:53

Я заметил, что удаление Центра программного обеспечения и скоростей передачи данных установки приложения способный кэш довольно много теперь, когда я использую синаптический диспетчер пакетов...

Michael Hale · Answer 5 · 11 June 2014 в 05:53

Согласно моему тестированию причины это настолько медленно, то, потому что apt-cache policy some-package выполняет итерации по дескрипторам файлов, пока это не поражает предельную ошибку.

~# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04 LTS"
~# ulimit -n 65535; time apt-cache policy snmpd
snmpd:
  Installed: 5.7.2~dfsg-8.1ubuntu3
  Candidate: 5.7.2~dfsg-8.1ubuntu3
  Version table:
 *** 5.7.2~dfsg-8.1ubuntu3 0
        100 /var/lib/dpkg/status

real    0m3.611s
user    0m0.432s
sys     0m0.264s
~# ulimit -n 100; time apt-cache policy snmpd
snmpd:
  Installed: 5.7.2~dfsg-8.1ubuntu3
  Candidate: 5.7.2~dfsg-8.1ubuntu3
  Version table:
 *** 5.7.2~dfsg-8.1ubuntu3 0
        100 /var/lib/dpkg/status

real    0m0.108s
user    0m0.011s
sys     0m0.016s

, Например, я вижу этот вид материала когда stracing процесс:

[pid 10447] fcntl(65534, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)
[pid 10447] getrlimit(RLIMIT_NOFILE, {rlim_cur=65535, rlim_max=65535}) = 0

я думаю, что это указывает на ошибку в способном кэше. Один hacky способ работать вокруг этого состоял бы в том, чтобы ограничить количество открытых файлов, но это могло вызвать вещи перестать работать излишне в некоторых случаях.

Почему apt-cache такой медленный?

5 ответов

Другие вопросы по тегам:

Похожие вопросы: