From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 24 Aug 2012 18:13:03 +0400 From: Alexey Tourbin To: ALT Linux Team development discussions Message-ID: <20120824141302.GE27787@altlinux.org> References: <20120822195649.GA23099@dad.imath.kiev.ua> <20120822211157.GA15257@t60p.mithraen.ru> <20120822212941.GA1465@altlinux.org> <20120823050344.GA23461@t60p.mithraen.ru> <20120823060622.GA5634@altlinux.org> <20120823163811.GA6658@t60p.mithraen.ru> <20120824005234.GD27787@altlinux.org> <20120824041241.GA25056@t60p.mithraen.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120824041241.GA25056@t60p.mithraen.ru> X-Mailman-Approved-At: Fri, 24 Aug 2012 21:27:01 +0400 Subject: Re: [devel] I: repocop test for %{get_version ...} is disabled. X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 14:13:03 -0000 Archived-At: List-Archive: List-Post: On Fri, Aug 24, 2012 at 08:12:41AM +0400, Денис Смирнов wrote: > On Fri, Aug 24, 2012 at 04:52:34AM +0400, Алексей Турбин wrote: > > > Какой смысл критиковать апт за поиск по тексту? Ты знаешь как он > > работает? Никакого вспомогательного индекса для этого нету, > > Только мне кажется что здесь первая и последняя фраза противоречат > друг-другу? :) Апт - это не поисковая система. Но он умеет искать по скоченным файлам методом их откупоривания и шестерения. Потихоньку так. > > он просто > > откупоривает скоченные pkglist.classic файлы и шестерит их. Логика - > > поиск всё равно выполняется пользователем, несколько секунд он подождет. > > 16 это не несколько, это дофига. И как раз такую простую операцию как > поиск я лично ожидаю в такой ситуации видеть за 1с максимум. Нет предмета для спора. :-) > AT> Либо ядро глючит, либо слишком мало RAM на машине (меньше 2G). > > $ free -m > total used free shared buffers cached > Mem: 3032 2829 203 0 122 1275 > -/+ buffers/cache: 1430 1601 > Swap: 3906 1165 2740 > > AT> Ядру ведь надо где-то взять 60 метров, чтобы этот файл в память загрузить, > AT> и еще несколько таких файлов есть. > > О ужас, оно еще и пытается целиком эти 60 метров втянуть? Там реально > нужен random доступ? Думаю, он читает этот файл по порядку, через rpmReadPackageHeader(), и в каждом загловке ищет совпадения. > AT> А если у тебя фаерфокс запущен, или, > AT> прости Господи, флеш плеер? Ядро оно что, должно тебе взять кредит в > AT> Банке реконструкции и развития? > > Запущены chromium и emacs. Два самых страшных монстра. Они неплохо > соревнуются кто из них монструознее :-/ > > Но, кажется, мне придется часть наездов на apt забрать назад. > apt-get install bash (в системе где он установлен) выполняется более 10-и > секунд (это повторный запуск, когда большинство уже в кэше). > > Виновник обнаружен: rpm-dir. Я ожидал, что при его использовании кэш > строится только при apt-get update, видимо это не так. rpm-dir работает таким образом, что каждый раз заново сканирует все пакеты в каталоге, причем из-за readahead(2) это означает, что каждый раз считывается 128K, т.е. 32 страницы, несмотря на то, что заголовок пакета может быть намного меньше. Я пробовал отрубить readahead в lib/package.c, не знаю работает или нет. Короче, не надо валить все проблемы на апт - и проповедовать новую чудесную "отечественную" систему, которая якобы решает все проблемы только в силу своей чудодейственной альтернативности. > Комментирование строчки с репозиторием (локальные сборки пакетов) сразу же > ускоряет в 5 раз. > > apt-cache search стал работать за 3 секунды, что хоть по моему мнению и > тормоза, но в приличных рамках. > > > -- > С уважением, Денис > > http://mithraen.ru/