Ускорение запуска приложений под kde

Как правильно узнать, какие библиотеки требуются конкретному приложению?

ldd

первый запуск (например kwrite) занимает 10 секунд

Это что же за железо такое?

А как он отнесется к тому факту что они будто постоянно выкидываются из памяти?

Уже загруженные библиотеки не выкидываются, пока кому-то нужны. Выкидывается кэш чтения (в который попадают и файлы библиотек, что делает их повторную загрузку мгновенной).

Спасибо за пояснение. А как узнать что же оно читает, чтобы поместить это в память заранее и как запретить выкидывать?

>>Это что же за железо такое?

Железо хорошее, просто загажено все видать.

Копай в сторону preload и, возможно, prelink. Хотя на последний расчитывать особо не стоит. Preload тоже особо ничего не гарантирует, но часто запускаемые программы должны стартовать быстрее.

strace -c как-то неадекватно считает время.

Приложение запускается несколько секунд, а оно показывает 0.01 sec в итоговой строке.

readahead-list советуют. В генте точно есть, про другие дистры не знаю.

Ага, вот strace -c быстрого запуска:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 58.67    0.000044           1        61           fadvise64
 22.67    0.000017           0       179           mmap
 18.67    0.000014           0       124           mprotect
  0.00    0.000000           0        93        10 read
  0.00    0.000000           0         3           write
  0.00    0.000000           0        92        13 open
  ....
------ ----------- ----------- --------- --------- ----------------
100.00    0.000075                   778        25 total

А вот медленного запуска (сразу после drop_caches):

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 50.64    0.003506          38        92        13 open
 32.25    0.002233          37        61           fadvise64
 14.66    0.001015         508         2           clone
  2.44    0.000169         169         1           wait4
  0.00    0.000000           0        93        10 read
  0.00    0.000000           0         3           write
  ....
------ ----------- ----------- --------- --------- ----------------
100.00    0.006923                   778        25 total

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

у меня в xfce можно заставить стартовать kde services и gnome services при запуске. у тебя как де? кеды?

Не исключаю эффекта плацебо, но мне показалось, что prelink в этом смысле реально помог. Хотя, конечно, не настолько драматично, как хотелось бы.

>>у меня в xfce можно заставить стартовать kde services и gnome services при запуске.

Судя по всему «kde services» это чисто xfce-шный термин и что за ним скрывается из списка в kcontrol>KDE Components>Service Manager - неизвестно.

Сервисы из списка Startup Services в kcontrol>KDE Components>Service Manager почему-то дохнут самостоятельно через минуту после явного запуска. Да и пофиг, ибо их включение и выключение никак не влияет на обсуждаемую багу.

>Ускорение запуска приложений под kde
это оксюморон же.
у треда нет логического завершения, у ТС нет светлого будущего в этой проблеме.

megabaks@desktop ~/envytools/build $ ldd /usr/bin/gimp
	linux-gate.so.1 =>  (0xb7867000)
	libgimpwidgets-2.0.so.0 => /usr/lib/libgimpwidgets-2.0.so.0 (0xb770a000)
	libgimpmodule-2.0.so.0 => /usr/lib/libgimpmodule-2.0.so.0 (0x41c1d000)
	libgimpcolor-2.0.so.0 => /usr/lib/libgimpcolor-2.0.so.0 (0x4e6c0000)
	libgimpthumb-2.0.so.0 => /usr/lib/libgimpthumb-2.0.so.0 (0x4d208000)
	libgimpmath-2.0.so.0 => /usr/lib/libgimpmath-2.0.so.0 (0x4e6e5000)
	libgimpconfig-2.0.so.0 => /usr/lib/libgimpconfig-2.0.so.0 (0x4e6ed000)
	libgimpbase-2.0.so.0 => /usr/lib/libgimpbase-2.0.so.0 (0x4e6ce000)
	libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb733b000)
	libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb72a4000)
	libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb7287000)
	libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb727b000)
	libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb7188000)
	libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb715f000)
	libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb711b000)
	libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb70eb000)
	libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7063000)
	libgegl-0.1.so.0 => /usr/lib/libgegl-0.1.so.0 (0xb700b000)
	libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x4e700000)
	libbabl-0.1.so.0 => /usr/lib/libbabl-0.1.so.0 (0xb6fbd000)
	libm.so.6 => /lib/libm.so.6 (0xb6f95000)
	libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x4e654000)
	libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x4e3f0000)
	libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x4e197000)
	libpthread.so.0 => /lib/libpthread.so.0 (0xb6f7b000)
	libc.so.6 => /lib/libc.so.6 (0xb6dfb000)
	libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x4e697000)
	libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb6df5000)
	libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb6dd9000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0xb6cb8000)
	libXi.so.6 => /usr/lib/libXi.so.6 (0xb6ca9000)
	libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb6c9f000)
	libXext.so.6 => /usr/lib/libXext.so.6 (0xb6c8f000)
	libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb6c85000)
	libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb6c81000)
	libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb6c7d000)
	libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb6c72000)
	libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb6c00000)
	libpng14.so.14 => /usr/lib/libpng14.so.14 (0xb6bd8000)
	libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb6bbd000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0xb6bb9000)
	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6bb2000)
	libGL.so.1 => //usr/lib/opengl/nvidia/lib/libGL.so.1 (0xb6ae7000)
	libEGL.so.1 => /usr/lib/libEGL.so.1 (0xb6ad9000)
	libdl.so.2 => /lib/libdl.so.2 (0xb6ad5000)
	librt.so.1 => /lib/librt.so.1 (0xb6acb000)
	libz.so.1 => /lib/libz.so.1 (0x4e16c000)
	libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb6aa1000)
	libresolv.so.2 => /lib/libresolv.so.2 (0xb6a88000)
	/lib/ld-linux.so.2 (0xb7849000)
	libimf.so => /opt/intel/Compiler/11.1/072/lib/ia32/libimf.so (0xb6823000)
	libintlc.so.5 => /opt/intel/Compiler/11.1/072/lib/ia32/libintlc.so.5 (0xb67df000)
	libnvidia-tls.so.256.53 => //usr/lib/opengl/nvidia/lib/libnvidia-tls.so.256.53 (0xb67dd000)
	libnvidia-glcore.so.256.53 => /usr/lib/libnvidia-glcore.so.256.53 (0xb52b0000)
megabaks@desktop ~/envytools/build $ 

man prelink, preload, GOPreload...

>почему-то через какое-то время приложения ведут себя так, как если бы я сделал drop_cashes руками
ууу...что такое кэш и что с ним происходит ты видимо не знаешь!?

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

А знаний, нужных, чтобы ответить «man prelink, preload, GOPreload», у меня уже имеется, спасибо.

у меня с prelink и c preload жутко начинаю глючить Qt приложения

я ж говорил - прелинк не привносит проблем
а прелоад впринципе никак не может - он тупо загружает некоторый набор либ - всё

Почему тут говорится, что preload никак не способен облегчить последствия drop_caches?

http://open-suse.ru/modules/newbb/viewtopic.php?post_id=16992#forumpost16992

>где принимается решение
в ядре )
изучай вирт память...только зачем?
vm.swappiness=20
vm.page-cluster=0
vm.dirty_ratio=5
vm.dirty_background_ratio=2
vm.dirty_expire_centisecs=100
vm.dirty_writeback_centisecs=100
vm.vfs_cache_pressure=1000
vm.overcommit_memory=1
это очень злые десктоп настройки оной

preload нет, а вот ---> http://forums.gentoo.org/viewtopic-t-789818-view-next.html?sid=5457cff93039fc...
вроде как может

Ну короче настроил я preload для konsole, как описано тут:

http://old-en.opensuse.org/SUPER_preloading

Все равно (как, впрочем, и ожидалось) после принудительного drop_caches старт konsole такой же медленный.

Но проблема была в том что через некоторое время после первого запуска кэш выветривался и сам, без явного указания его очистки.

Посмотрим, как preload повлияет на скорость выветривания кэша.

ты вообще читаешь что тебе пишут?
или ты за К.О. сегодня?

Расскажи, откуда, по-твоему, нужно было сделать вывод о том, как системный вызов posix_fadvise, используемый в preload, влияет на прочность удержания файлового кэша.

По результатам моего эксперимента нужный кэш konsole держится уже 7 часов, тогда как без preload он выветрился бы за полчаса при активной раздаче торрентов например.

а прелоад тупо загружает некоторый набор либ - всё

В том-то и дело, что не только либ, но и просто файлы для чтения. Вот из настроек preload для konsole:

open /usr/lib/locale/en_US.utf8/LC_ADDRESS
open /etc/fonts/conf.d/40-generic.conf
open /usr/lib/locale/en_US.utf8/LC_TIME
open /usr/share/fonts/truetype/DejaVuSansMono-Bold.ttf

Видна загрузка простых текстовых файлов.

>>По результатам моего эксперимента нужный кэш konsole держится уже 7 часов, тогда как без preload он выветрился бы за полчаса при активной раздаче торрентов например.

Не, увы, все херня, при раздаче dc++ через пару часов кэш достиг 2 Gb и konsole-вские прелоады выкинул.

да ж тож ты так тупишь?
GOPreload!!!

Это что же за железо такое?

Железо хорошее, просто загажено все видать.

А не лучше ли тогда все «разгадить» чем городить куча костылей, пытаясь это разогнать?

>>да ж тож ты так тупишь?

По голове себе стукни.

Я журналирую свои наблюдения с той скоростью, с которой у меня появляются новые данные.

Про preload был конкретный вопрос, ответ на который можно было получить лишь экспериментально (если не знать наизусть сорцы ядра).

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

>>я же сказал что preload не умеет держать в оперативе!

Сходил бы чайку попил.

Если под «умение держать в оперативе» понимать способность устоять против прямой команды drop_caches, то этот вопрос давно проехали и не обсуждается - не умеет, ясно.

Вопрос был в другом: как preload повлияет на скорость выветривания кэша, а это свойство, (как ты, надеюсь, понимаешь), абсолютно ортогональное «умению держать в оперативе» в обозначенном выше понимании.

>>А не лучше ли тогда все «разгадить»

What_has_been_zagajeno_cannot_be_razgajeno.jpg

http://welinux.ru/post/4499/

С помощью gopreload удалось ускорить загрузку konsole сразу после после drop_caches с 6-7 до 3 секунд. Однако повторный запуск происходит все равно куда быстрее - мгновенно.

каноникал говорил что прелинк до лампочки

+1 за prelink. Нужно только не забывать его запускать периодически, например, после обновлений.

Насколько я помню, именно в случае с KDE prelink чисто теоретически должен иметь эффект. Ну и вроде как я его наблюдаю, хотя самовнушение, конечно, страшная сила :)