Anonymous | Login | Signup for a new account | 21-11-24 12:51 UTC |
All Projects | SAS.Планета | Домен, сайт, форум, багтрекер | Доработка карты (ZMP) | Переводы и локализации | Прочее |
My View | View Issues | Change Log | Roadmap | Search |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0000810 | SAS.Планета | [All Projects] Баг | public | 20-06-2011 05:28 | 02-08-2012 05:27 | ||||
Reporter | Parasite | ||||||||
Assigned To | Parasite | ||||||||
Priority | high | Severity | block | Reproducibility | random | ||||
Status | closed | Resolution | no change required | ||||||
Platform | Windows | OS | Server | OS Version | 2003 | ||||
Product Version | 110427.Beta | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0000810: Блокирование системы при долгой работе | ||||||||
Description | При относительно долгой плотной и непрерывной работе с коннектами\скачками - бетка вешает систему. Начинает проявляться всё с некоторых вкраплений строчек "Недостаточно системных ресурсов для завершения операции" в окне скачек. Со временем эти строчки появляются плотнее и плотнее, и в итоге в один прекрасный момент САС валит винду в pre-DDOS: .из динамиков раздается повторяющийся звук системного еррора (эдакая "дробь"), при этом самого еррора - не выводится .все остальные работающие до этого приложения не могут получить доступ к сети (ни к интернету ни к локалке) .закрыть САС невозможно - он не реагирует ни на какие тычки в ГУЙ .в системе невозможно запустить новых процессов (даже таскманагера - для прибития САСа) Помогает лишь прибитие самой винды (кнопкой ресет, или жестким перезапуском вирт.машины). | ||||||||
Steps To Reproduce | Глюк резко подкрадывается ближе, если сами тайлы лежат не на винте а на удаленном сетевом хранилище - при этом может выбить винду примерно за 15...20 часов непрерывной работы. При этом строки лога "Недостаточно системных ресурсов для завершения операции" перемежаются множащимися строками "Ошибка - невозможно сохранить файл <\\Server\path\file>" или как-то так. О точных причинах сказать ничего не могу - на момент его появления ничего запустить\проверить уже не представляется возможным, система просто дохнет. В сильно-прошлых версиях (например юзаю 100330) - этого глюка ни разу не было. Качает по полгода без остановки - и ничего. | ||||||||
Additional Information | Подозреваю, что где-то что-то не смывается в сокетах, и винде в конце концов сносит башню. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Notes | |
(0002992) Parasite (administrator) 20-06-2011 05:31 |
Возможно, связано с тикетом 434. Не уверен - слово за разработчиками. |
(0002995) vdemidov (manager) 20-06-2011 06:21 |
Насилуй дебажную версию. Никаких идей нету. |
(0002997) Tolik (manager) 20-06-2011 07:04 |
А ещё интересно, наверное, погонять последний ночной билд. Там какие-то утечки памяти были пофиксены. |
(0002998) vdemidov (manager) 20-06-2011 07:15 |
Пофиксены утечки, которые в нем же и добавлены :) |
(0003000) gpsMax (manager) 20-06-2011 09:27 edited on: 20-06-2011 09:31 |
У меня тут батником качаются некоторые вещи. Так вот, через несколько дней непрерывной работы как раз начинаются ошибки "Ошибка доступа" при записи файлов на диск и приходится перезагружаться - системе сносит башню, работать уже нельзя вообще никак. Какая-то виндовая ошибка, имхо, не связанная с САСом. Семерка x64 SP1, что самое обидное. Типа последнее поколение майкрософтовских систем. |
(0003002) Parasite (administrator) 20-06-2011 10:51 |
>Какая-то виндовая ошибка, имхо, не связанная с САСом. Почему-то эта "виндовая ошибка не связанная с САСом" никак не проявляется с экзешниками прошлых версий (всё остальное - то же самое: карты, хранилища кэша и сам кэш, метки, и даже собственно конфиги практически идентичны). В какой конкретно версии началось - не подскажу, так как юзал и юзаю 100330 (глюка нет) и решил попробовать текущую бетку (глюк есть, и он повторяем). Где-то на этом промежутке в полтора года его и прикодили... :) PS: в качестве временного решения откатился назад на 100330. Мониторю тикет. :) |
(0003004) vdemidov (manager) 20-06-2011 11:22 |
Мониторь, но толку то? Я даже не подозреваю в чем может быть проблема. Так что без дополнительной инфы 2015 год или позже. |
(0003007) gpsMax (manager) 20-06-2011 12:33 edited on: 20-06-2011 12:34 |
Подозреваю, что причина не в сокетах, а как раз в дисковых операциях. На это же намекает и упоминание про сетевое хранилище. И причина, уверен, локально виндовая. |
(0003010) Parasite (administrator) 20-06-2011 19:00 edited on: 20-06-2011 19:05 |
>Так что без дополнительной инфы 2015 год или позже. Как только - так сразу. Не раскачивай лодку - для меня каждое обновление как серпом по...ну, просто серпом. :) Основной порн в том, что оно валит всю систему - а у меня в оной как правило далеко не единственный САС и жестко ребутать дохлую VM и терять данные с соседних задач потом мне не с руки. А отдельную запускать - жирновато будет.... :) Скачаю дебажную версию, погоняю, отпишуся. >что причина не в сокетах, а как раз в дисковых операциях. Какие еще "дисковые операции" при сетевом хранилище? Те же самые сетевые соединения, только порт\протокол другие. Дисковые же операции идут на другой стороне мира, я их не вижу\никогда там не был\отношения к ним вообще не имею, оно просто работает да и все. И, опять же - повторяю: на версии 100330 всё ок (на том же удаленном хранилище). Вот прямо сейчас в пяткЕ-десятке копий запущено, с десятком процессов в каждой. И еще несколько в задачах висят полгода уже без перекура. Работают себе.... Стоило врубить бетку парой дней назад - и началось шоу. |
(0003040) Parasite (administrator) 23-06-2011 14:48 |
UPD: .баг проявляется (и повторяется) на текущей бете + последние (июньские) автоапдейты от винды'2003Serv. .баг НЕ проявляется на 100330 + последние (июньские) автоапдейты от винды'2003Serv. .баг НЕ проявляется на текущей бете без последних автоапдейтов от винды'2003Serv. То ли в последнем автоапдейте что-то отломали от Винды, то ли последняя бета с ним конфликтует. |
(0003043) feya (manager) 23-06-2011 18:58 edited on: 24-06-2011 10:02 |
Parasite, может попробуешь предыдущие релизные версии, хоть сузим временные рамки. |
(0003133) Parasite (administrator) 10-07-2011 04:29 |
Проблема в изменении логики KernelPagedPool в последних апдейтах для вин2003серв. При активных многочисленных коннектах [сейчас] выюзываюся все доступные системные хэндлеры, и почему-то не закрываются\не смываются (либо таймауты закрытия у них стали намного выше - не разбрирался). В любом случае, это системный глюк(?) или даже фича, а САС просто вступает в нее всем фейсом при активной работе. Я специально сделал постороннюю программку, активно выюзывающую хэндлеры. Проблема повторилась. :( PS: в вин7 тоже эта проблема есть, судя по гуглу: https://media.blackhat.com/bh-dc-11/Mandt/BlackHat_DC_2011_Mandt_kernelpool-wp.pdf и кучка KB's у самого Микрософта (где "Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section" ©). В общем, кривость винды в своем репертуаре. Отломали даже то, что раньше как-то работало. |
(0003134) gpsMax (manager) 10-07-2011 19:56 edited on: 10-07-2011 19:58 |
Большое спасибо за раскопки. Таки да, похоже, в Win7 эта проблема наличествует в полный рост, о чём писал выше. Симптомы удивительно точно описаны еще в описании тикета. Поскольку майкрософт патчить это дело не спешит ни в 2003, ни в 7, есть мысли по обходу этой багофичи? |
(0003138) Parasite (administrator) 11-07-2011 07:49 |
>Таки да, похоже, в Win7 эта проблема наличествует в полный рост, о чём писал выше. А меня почему-то напрягает то, что на более старой версии глюк таки НЕ ВОСПРОИЗВОДИТСЯ. То ли она просто медленнее работает и всё за ней успевает вовремя подчищаться даже со штатными таймаутами, то ли в новой что-то менялось как минимум в сторону работы с тайлами\сокетами\открытием-закрытием оных. Кстати, заметил также что при проверке кэша (уже имеющегося) в старой версии лог в окне закачки непрерывно бежит, а в новой - скроллится раз в секунду (при этом кол-во отработанных за секунду тайлов примерно равное в обоих случаях). Оно конечно к хэндлерам не очень близко - но как минимум показывает, что что-то где-то в процедуре скачки\проверки менялось и ВОЗМОЖНО причина сидит где-то рядом со всем этим. Не уверен, обгонять не буду. :) >есть мысли по обходу этой багофичи? Мысли-то есть, а вот обходов - пока нету. Пока суть да дело - ссадил САСа с винды обратно в выня. Неделя - полет пока что нормальный... :) |
(0003139) vdemidov (manager) 11-07-2011 07:59 |
Может и в этом дело. Раньше, после закачки тайла, поток закачивалки останавливался и ждал основной GUI-поток, что бы вывести сообщение в лог, а сейчас он просто добавляет его в буфер, а уже GUI-поток по таймеру проверяет этот буфер и выводит новые сообщения на экран. Так что раньше (это было ну очень давно) получалась естественная пауза после завершения закачки каждого тайла. Попробуй поставь в параметрах карты Sleep=1 |
(0003140) Parasite (administrator) 11-07-2011 09:38 |
>Попробуй поставь в параметрах карты Sleep=1 Так я выше говорил про проверку локального кэша (который уже скачан). Про ситуацию, когда в логе строчка "Тайл уже имеется в кэше". Там же Sleep вроде как уже не работает, какой смысл карту мучать? |
(0003141) vdemidov (manager) 11-07-2011 09:49 |
>Так я выше говорил про проверку локального кэша (который уже скачан). Про >ситуацию, когда в логе строчка "Тайл уже имеется в кэше". Там же Sleep вроде как >уже не работает, какой смысл карту мучать? Определись, проблема при закачке или проявляется и без обращения к http Если при закачке, то слип поможет. А если и без нее есть, то это совсем другое дело. |
(0003142) Parasite (administrator) 11-07-2011 11:09 |
>Определись, проблема при закачке или проявляется и без обращения к http На наст.время нет возможности сказать, вызывается баг на сокетах или на файловых операциях. На сайте Микрософта опять же есть KB и про то и про это (два про переполнения на сокетах и один - на хэндлерах\пуле ядра, все три - нерешаемые при попытке повторения рекомендуемых фиксов там). Записей в логах система при данном баге не оставляет, и какой конкретно из них имеет место быть - наверняка сказать невозможно. Все три детектируются по планке PagedKernelPool выше лимита для юзаемой системы, и это как раз то что у меня и светится при начале глюка. Обращения к http постараюсь изолировать, но сетевой трафик в моем случае будет _всегда_, увы (вся куча с кэшем - удаленная). Отпишусь позже, как результаты будут. |
(0003226) vdemidov (manager) 21-07-2011 05:22 |
Самая простая проверка, которую можно, для начала, сделать, это поставить карте Sleep в 1 милисекунду. На производительности не должно сильно сказаться, и будет эмулироваться работа очень старых версий, которые после скачки каждого тайла синхронизировались с основным GUI потоком. |
(0003234) gpsMax (manager) 21-07-2011 15:52 |
А номера статей KB можно озвучить? |
(0003290) gpsMax (manager) 02-08-2011 04:11 |
У меня в ивентах вот такая ошибка попадается перед залочиванием системы http://support.microsoft.com/kb/971905 RAID'ов нет. В инете есть несколько упоминаний, но без решений. http://social.technet.microsoft.com/Forums/ru-RU/windows7ru/thread/603e0edb-f863-40ce-8115-96c8bb981c06 http://forums.tophardware.ru/viewtopic.php?f=11&t=1628 Дисковые операции всё-таки, как минимум, в данном случае. Как избавиться - хз. |
(0003829) vdemidov (manager) 09-09-2011 20:33 |
Ну так как результаты экспериментов? Пробовал качать с задержкой в 1 мс? |
(0003870) zOn (reporter) 12-09-2011 04:57 edited on: 12-09-2011 04:57 |
Parasite, у вас случайно не установлен AnVir Task Manager? или еще какой монитор трафика. |
(0003873) gpsMax (manager) 12-09-2011 05:05 |
Интересный комбайн. Только вот мониторинг трафика он делать всё же не умеет, судя по всему. |
(0003875) zOn (reporter) 12-09-2011 05:07 |
Умеет, но у меня это приводило к BSOD http://sasgis.org/mantis/view.php?id=805 при длительной сетевой нагрузке. Он мониторит каждый процесс. |
(0003889) Parasite (administrator) 12-09-2011 10:24 |
>А номера статей KB можно озвучить? Ну конечно можно. >Пробовал качать с задержкой в 1 мс? Пока нет. Оно, зараза, с того времени и не падало (работая в wine), а стопорить ручками и грузить винду как-то повода не было больше. Как упадет - попробую. >у вас случайно не установлен AnVir Task Manager? Я даже не знаю что это. >Он мониторит каждый процесс. А в чём смысл мониторинга каждого процесса? |
(0003890) zOn (reporter) 12-09-2011 10:26 |
>А в чём смысл мониторинга каждого процесса? ну как бы здесь не об этом. мне удобно искать всякую бяку, которая сжирает сетевые ресурсы. |
(0003891) gpsMax (manager) 13-09-2011 04:38 |
>>А номера статей KB можно озвучить? >Ну конечно можно. :-) |
(0004094) gpsMax (manager) 17-10-2011 04:33 edited on: 17-10-2011 04:43 |
Апдейт темы. Почитав некоторое время назад журнал событий, увидел там ошибки NTFS (спасибо Паразиту за наводку), далее почитал про эту систему в общем и частном. Для меня, кстати, было неприятным открытием, что мелкие файлы она хранит прямо в таблице размещения файлов, которая от этого раздувается и дико тормозит, но это к слову. Я сделал другой контейнер, отформатировал его в exFAT, новую майкрософтовскую файловую систему. Сразу же порадовался нормальной скорости работы на том же наборе файлов, и огорчился отсутствию сжатия - многое в тот же объём не влезло, увы. Пришлось убрать ещё пару редко используемых карт. Снова начал качать тайлы пачками. Через несколько дней, как и прежде, словил блокировку системы. Теперь можно утверждать, что это не зависит от файловой системы. В журнале событий пусто. У меня тут процесса, собственно, два - массовая закачка тайлов САС.Планетой и массовая их обработка скриптами. Первый генерит преимущественно сетевые запросы, второй с сетью работает мало, зато активно дёргает диск. К сожалению, на момент сбоя было запущено и то, и другое. Через некоторое время постараюсь провести более чистый эксперимент. Номера KB и коды/источники событий при блокировке системы всё-таки были бы полезны. |
(0004095) Parasite (administrator) 17-10-2011 05:55 |
>Почитав некоторое время назад журнал событий, увидел там ошибки NTFS Вечером перечитывал пейджер. Много думал...(с) :) Вышеописанный баг может проявляться в самых разных ипостасях, в первую очередь он бьет в темечко процессам и устройствам, активно юзающим kernel pool (сюда относятся такие "нативные" и "жестко вшитые" для винды операции, как работа с драйверами FS, драйверами оборудования и проч). ntfs.sys, tcpip.sys, extfs.sys и прочие *.sys подвержены в первую очередь, так как работают напрямую с ядром - насколько я знаю архитектуру винды. Отсюда при появлении бага - он может вылезти где угодно, вероятность появления в вышеуказанных критических местах - соответственно, максимальна и равновероятна. Что мы и наблюдаем: у меня при активной работе с сетевыми дисками - отваливается весь протокол (tcpip.sys), у камрадов при активной работе с дисками - отваливаются FS (ntfs.sys/exfat.sys), и проч. Баг же - один: переполнение свопа ядра (ну или утечки в чем-то, что приводит к переполнению). Баг известен Микрософту, работы ведутся © (с 2003 года как минимум - когда я сам лично им писал об этом - и они мне сказали, что это known problem of the Microsoft product). >Для меня, кстати, было неприятным открытием, что мелкие файлы она хранит прямо в таблице размещения файлов, которая от этого раздувается и дико тормозит, но это к слову. Еще больше Вам доставит попытка дефрагментации такого диска, ибо оно будет дефрагментировать один непрерывный файл ($Mft) меееелкими кусочками (тайлами внутри оного), и если места на диске будет мегьше чем текузий $Mft - то на середине процесса оно либо скажет что недостаточно памяти для завершения операции, либо тупо схлопнет процесс дефрагментации (а так как он аварийно схлопнется на процедуре модификации именно $Mft - то ничем хорошим это не грозит). В особо циничных случаях подчистую слетает весь раздел диска - винда говорит, что на разделе она нашла ФС "RAW", и еще более цинично предлагает отформатировать. :) >это не зависит от файловой системы. Боян. Вот, собссно, разбор полетов и даже тулзы для воспроизводства бага от гуру ковыряния в винде (лично я нижеприведенную там картинку "Insufficient resources" вижу примерно раз в неделю): http://blogs.technet.com/b/markrussinovich/archive/2009/03/26/3211216.aspx http://blogs.technet.com/b/markrussinovich/archive/2009/09/29/3283844.aspx ...правда на этом и всё, ибо радикального и однозначного решения этому багу пока что нет. "Протекать" может даже не САС и даже не один из его компонентов, а например tcpip.sys или еще что-либо фундаментальное и юзаемое САСом - благо что проблема-то не только с САСом, а и вообще. Например на торрентах - весьма часто ловится (тоже весь протокол отваливается, либо диск). Тоже народ локти кусает, греша на приложение а не на саму винду... http://forum.utorrent.com/viewtopic.php?pid=167057 |
(0005261) Parasite (administrator) 30-01-2012 06:03 |
Итак, продолжаем сабж свежепоявившимися деталями. Вчера я токи решил поплотнее заняться вопросом, ибо винда под плотной закачкой последней ночнушкой не проживает и 2х суток(!). И токи занялся. Выяснилось, что в моей винде с момента ее рестарта и до момента скукоживания - ПОСТОЯННО растет число USER и GDI объектов, причем чем более плотно идет работа - тем более быстро они растут. При достижении дефолтного лимита системы на число этих объектов (10.000 на кадждый, если не ошибаюсь) - получаем глюки, баги, выпадения частей гуя с разных окон, системные бибиканья еррором в динамик, мессаги "Недостаточно системных ресурсов" в лог и прочая прелести описанные в первом посте. Причем замечено, что число этих объектов растет и БЕЗ САСа - просто без него раза в 2-3 медленнее, чем с ним. Далее была заюзана вот эта тулза для мониторинга GDI/USER pools: http://www.downloadcrew.com/article/25850-bear Выяснилось, что респаунит эти объекты не САС, не какая-то стороняя програма - а нащ старый знакомый explorer.exe, широко известный в узких кругах. При холодном старте и начале мониторинга он держит в GDI/USER пулах соответственно 318/254 объекта, при скукоживании винды - около 4х тысяч на каждый, что вкупе с другими программами и переваливало за системный лимит дня через 2-3. Остальные программы более-менее держали свои объекты на постоянном уровне, и при закрытии себя - схлопывали свои объекты и освобождали ресурсы. Эксплорер же в винде просто так не закрыть, кроме как кильнуть через 3 кнопки - что не есть расово верно. Далее, был помониторен оный же эксплорер в безопасном режиме винды (с отключением всех левых драйверов\сервисов, могущих лезть в адресное пространство explorer.exe). Рост числа объектов не прекратился. Далее, система была просто загружена в САМОМ минимальном состоянии с убитием всего до чего дотянулись руки - по большому счету осталось только ядро, эксплорер и несколько драйверов и критических сервисов. Система была оставлена в таком виде в покое на несколько часов - не шевелили даже мышку. Рост числа объектов НЕ наблюдался, счетчик стоял стабильно. Но с момента начала шевеления мышкой и проверки процессов\итд - счетчик ОПЯТЬ полез вверх, хотя ничего нового не было запущено. Путем кучки телодвижений, матюков, пива и чьей-то матери пришло понимание того, что в данном конкретном моем случае число объектов GDI:Bitmap росло на +1, а число USER:Menu росло на +3 при КАЖДОМ ПРАВОКЛИКЕ МЫШОЙ В ЭКСПЛОРЕРЕ (и только в нем). То есть, вызов правокликовой менюшки и ее закрытие - получаем +4 объекта, и так далее пока не упремся в системный лимит на оные. Это касалось кликов на файлах, папках и десктопе, короче - Эксплорер во всей его красе. При помощи всё той же тулзы было просмотрено, что же содержат новосоздаваемые объекты, и в конце концов хвост проблемы был пойман: * В КАЖДОМ новосозданном GDI:Bitmap обьекте хранилась иконочка от программы Unlocker (махонькая, та самая которая отрисована в правокликовой менюшке эксплорера при установленном анлокере), и не киляется при деструкции меню; * В КАЖДОМ из трех новосоздаваемых USER:Menu обьекте хранились меню, создаваемые программой TeraCopy из правоклика на файле\папке (Копировать в\Переместить в\Фэворитс...), и не киляются при деструкции меню. Отключение обоих двух ShellExtension и рестарт эксплорера - решили проблему радикально: уже сутки счетчик GDI\USER практически стоит на месте в чистом эксплорере. Вопрос с Анлокером решился просто: у меня была старая версия (1.6.0), а в чейнджлоге на версию 1.8.1 видим радующую глаз строчку: "Fixed bug: Unlocker leaked Icon GDI objects". Обновил его до последней версии, включил ShellExtension - пока что полет нормальный, иконка вроде бы больше не утекает. Вопрос с ТераКопи пока под вопросом: сама программа работоспособна и из нее самой вроде бы ничего не утекает (да и закрывается она полностью после работы, освобождая все свои ресурсы), и проблема ТОЛЬКО с ее модулем встраивания в правоклик. Программа работоспособна и без него, но с оным - намного удобнее в работе. Наверное отпишусь автору прожки, пускай обратит внимание - авось пофиксит утечку. PS: при работе САСа счетчик GDI:Bitmap + SystemHandlers также растет вверх, но не очень быстро - и решается просто перезапуском САСа. Возможно, где-то что-то не смывается, и оно тоже в конце концов упиралось в лимит системы - отсюда был и 1й пост. Помониторю еще. PPS: по этой же методе был помониторен и ноутбук. Тоже нашлась утечка, GDI тикал на +1 и не смывался каждое нажатие левого Шифта. Оказалось, что виноват был режим StickyKeys - отключение его в дупу першило вопрос. Программерам САСа - мои извинения за ложную тревогу, грабли в данном конкретном случае были не в САСе. Тикет прошу оставить на месте - авось еще кому поможет. В общем, мониторьте систему - некоторые проблемы в работе САСа могут быть не связаны с багами программы САС напрямую, и как говорится - кто бы мог подумать, что по сути ненужная иконка Анлокера может блокировать запись сасового кэша в сетевое хранилище (см.первый пост).... ;) |
(0005262) vdemidov (manager) 30-01-2012 06:19 |
Все равно не понятно, почему наличие запущенного САСа ускоряло процесс утекания ресурсов. И если продолжает утекать, но медленнее, то лечить все равно нужно. |
(0005264) Parasite (administrator) 30-01-2012 06:38 edited on: 30-01-2012 07:01 |
Нужно, но статус тикета можно сменить с радикальной аварии на обычный или даже низкий, бо безболезненно перезапустить САСа гораздо проще, чем перезапустить эксплорера. А утекание под сасом возможно вызвано большим числом хэндлеров на к.тайл, и медленным их закрытием в системе по таймауту - особенно в случае сетевых операций, упомянутых в первом посте. То есть, это скорей всего даже не утекание, а фича работы оси - бо тайлы качаются быстрее чем таймаутятся, и подкручивание оси на предмет таймаута наверное решит проблему. Имхо. Помониторю еще, если чего интересного еще найду - доложусь. |
(0005266) vasketsov (manager) 30-01-2012 10:15 |
>Unlocker Вот спасибо за исследование. А то стоит виста без анлокера - работает и качает многосутками. А XP с анлокером на ночь всегда вырубаю, иначе утром ей уже плохо бывает. Хотя изначально я б сделал противоположные ставки на сравнительную усточивость этих двух систем. |
(0005267) Parasite (administrator) 30-01-2012 14:04 edited on: 30-01-2012 14:05 |
>А то стоит виста без анлокера - работает и качает многосутками. А XP с анлокером на ночь всегда вырубаю, иначе утром ей уже плохо бывает. Ну я описал только сугубо свое ковыряние - в Вашем случае может быть совершенно другая причина. У меня просто был _действительно_ старый Анлокер, от 2005го года если не ошибаюсь. Попробуйте, ссылка на тулзу выше дана. Запускаете тулзу, ставите ее AlwaysOnTop, и вызываете пару десятков раз правоклик на любом файле. Если число "Bitmap" в процессе Explorer.exe увеличилосбь на число правокликов - то это оно. Даблкликаете в тулзе на эксплорере - откроется список объектов. Смотрите, какие последние Bitmap - и что в них содержится. Медитируете, материтесь, делаете выводы и телодвижения. :) |
(0005281) gpsMax (manager) 31-01-2012 20:14 |
Шаман, однако! Мегареспект за копание в таких глубинах системы. |
(0005285) Parasite (administrator) 01-02-2012 04:58 |
>копание в таких глубинах системы. Ну не такие уж и глубины, собсственно. Основы виндоГУЯ, будь он неладен. ХПшным системам уже более 10и лет с момента выпуска, при установке оной - ставятся дефолтовые настройки\оптимизации по состоянию "как оно было юзабельно 10 лет назад" - в время-то идет, и кол-во данных\софта\запросов к ресурсам у пользователя за это время несколько выросло. Да и сегодняшнее среднестатистическое железо отличается от оного же в 2001м году раз так в несколько, и соответственно - может много больше, чем система ставит в настройках по умолчанию и в кои среднестатистический хомяк никогда и не лазит, пока всякие твикеры не начнет ставить. Посему для начала дохтур рекомендует подкрутить системные лимиты GDI\USER (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\(GDI|USER)ProcessHandleQuota) токи до максимума (лично я себе крутанул с 10К до 30К и тех и других), а уж потом не спеша искать утечки в том, что и так работало. PS: кстати, а неплохой эксплоит для винды получится - и все антивири пропустят. Мелкая программка или даже быдлоскриптиик, создающий over9999 пустых GDI+USER -обьектов - и Эксплорер гарантированно выйдет отдохнуть (а за ним и вся винда сразу же после первого же запроса на создание GDI\USER - бо без гуя она неработоспособна в принципе). А антивири пропустят потому что деструктивного кода не несет - создание GDI\USER обьекта по запросу есть фича оси. :) |
(0008037) Parasite (administrator) 02-08-2012 05:27 |
>а уж потом не спеша искать утечки в том, что и так работало. Гадость не спеша токи найдена: причиной был глючный Outpost Firewall, подвешивающий некоторые сокеты со своей стороны при долгой работе и высокой нагрузке (особенно при качании на сетевые шары). Рестарт закачки в сасе просто открывал новый тред, работавший до поры до времени - но старый так и висел, и в определенный момент очередь свободных сокетов выюзывалась до нуля -> извольте ребутаться. Удаление Outpost Firewall решило проблему - теперь скАчки идут месяцами. |
Issue History | |||
Date Modified | Username | Field | Change |
20-06-2011 05:28 | Parasite | New Issue | |
20-06-2011 05:31 | Parasite | Note Added: 0002992 | |
20-06-2011 06:21 | vdemidov | Note Added: 0002995 | |
20-06-2011 06:21 | vdemidov | Status | new => feedback |
20-06-2011 07:04 | Tolik | Note Added: 0002997 | |
20-06-2011 07:15 | vdemidov | Note Added: 0002998 | |
20-06-2011 09:27 | gpsMax | Note Added: 0003000 | |
20-06-2011 09:28 | gpsMax | Note Edited: 0003000 | View Revisions |
20-06-2011 09:29 | gpsMax | Note Edited: 0003000 | View Revisions |
20-06-2011 09:31 | gpsMax | Note Edited: 0003000 | View Revisions |
20-06-2011 10:51 | Parasite | Note Added: 0003002 | |
20-06-2011 10:51 | Parasite | Status | feedback => new |
20-06-2011 11:22 | vdemidov | Note Added: 0003004 | |
20-06-2011 11:50 | vdemidov | Status | new => feedback |
20-06-2011 12:33 | gpsMax | Note Added: 0003007 | |
20-06-2011 12:34 | gpsMax | Note Edited: 0003007 | View Revisions |
20-06-2011 19:00 | Parasite | Note Added: 0003010 | |
20-06-2011 19:00 | Parasite | Status | feedback => new |
20-06-2011 19:05 | Parasite | Note Edited: 0003010 | View Revisions |
23-06-2011 14:48 | Parasite | Note Added: 0003040 | |
23-06-2011 18:58 | feya | Note Added: 0003043 | |
24-06-2011 10:02 | gpsMax | Note Edited: 0003043 | View Revisions |
28-06-2011 11:35 | Tolik | Status | new => acknowledged |
10-07-2011 04:29 | Parasite | Note Added: 0003133 | |
10-07-2011 19:56 | gpsMax | Note Added: 0003134 | |
10-07-2011 19:58 | gpsMax | Note Edited: 0003134 | View Revisions |
11-07-2011 07:49 | Parasite | Note Added: 0003138 | |
11-07-2011 07:59 | vdemidov | Note Added: 0003139 | |
11-07-2011 08:00 | vdemidov | Assigned To | => vdemidov |
11-07-2011 08:00 | vdemidov | Status | acknowledged => feedback |
11-07-2011 08:00 | vdemidov | Assigned To | vdemidov => |
11-07-2011 09:38 | Parasite | Note Added: 0003140 | |
11-07-2011 09:38 | Parasite | Status | feedback => new |
11-07-2011 09:49 | vdemidov | Note Added: 0003141 | |
11-07-2011 09:49 | vdemidov | Status | new => feedback |
11-07-2011 11:09 | Parasite | Note Added: 0003142 | |
11-07-2011 11:09 | Parasite | Status | feedback => new |
14-07-2011 08:28 | Tolik | Status | new => acknowledged |
21-07-2011 05:22 | vdemidov | Note Added: 0003226 | |
21-07-2011 05:22 | vdemidov | Status | acknowledged => feedback |
21-07-2011 09:07 | vdemidov | Relationship added | related to 0000550 |
21-07-2011 15:52 | gpsMax | Note Added: 0003234 | |
02-08-2011 04:11 | gpsMax | Note Added: 0003290 | |
09-09-2011 20:33 | vdemidov | Note Added: 0003829 | |
12-09-2011 04:57 | zOn | Note Added: 0003870 | |
12-09-2011 04:57 | zOn | Note Edited: 0003870 | View Revisions |
12-09-2011 05:05 | gpsMax | Note Added: 0003873 | |
12-09-2011 05:07 | zOn | Note Added: 0003875 | |
12-09-2011 10:24 | Parasite | Note Added: 0003889 | |
12-09-2011 10:24 | Parasite | Status | feedback => new |
12-09-2011 10:26 | zOn | Note Added: 0003890 | |
13-09-2011 04:38 | gpsMax | Note Added: 0003891 | |
14-09-2011 06:05 | vdemidov | Status | new => feedback |
17-10-2011 04:33 | gpsMax | Note Added: 0004094 | |
17-10-2011 04:38 | gpsMax | Note Edited: 0004094 | View Revisions |
17-10-2011 04:43 | gpsMax | Note Edited: 0004094 | View Revisions |
17-10-2011 05:55 | Parasite | Note Added: 0004095 | |
17-10-2011 05:55 | Parasite | Status | feedback => new |
30-01-2012 06:03 | Parasite | Note Added: 0005261 | |
30-01-2012 06:19 | vdemidov | Note Added: 0005262 | |
30-01-2012 06:38 | Parasite | Note Added: 0005264 | |
30-01-2012 07:01 | Parasite | Note Edited: 0005264 | View Revisions |
30-01-2012 10:15 | vasketsov | Note Added: 0005266 | |
30-01-2012 14:04 | Parasite | Note Added: 0005267 | |
30-01-2012 14:05 | Parasite | Note Edited: 0005267 | View Revisions |
31-01-2012 20:14 | gpsMax | Note Added: 0005281 | |
01-02-2012 04:58 | Parasite | Note Added: 0005285 | |
14-02-2012 21:28 | vdemidov | Status | new => resolved |
14-02-2012 21:28 | vdemidov | Resolution | open => no change required |
14-02-2012 21:28 | vdemidov | Assigned To | => Parasite |
17-02-2012 16:14 | Tolik | Status | resolved => closed |
17-02-2012 16:14 | Tolik | Assigned To | Parasite => |
17-02-2012 16:14 | Tolik | Assigned To | => Parasite |
02-08-2012 05:27 | Parasite | Note Added: 0008037 |
My View | View Issues | Change Log | Roadmap | Search |
Copyright © 2007 - 2024 SAS.Planet Team |