Результаты поиска

Я только что начал работать над проектом ASP.NET , который я надеюсь открыть с открытым исходным кодом, как только он достигнет подходящей стадии. В основном это будет библиотека, которую могут использовать существующие веб-сайты. Я предпочитаю поддерживать ASP.NET 2.0 через 3.5 , но мне было интересно, сколько людей я оставлю, не поддержав ASP.NET 1.1 ? Более конкретно, сколько людей все еще используют ASP.NET 1.1 , для которых ASP.NET 2.0/3.5 не является вариантом? Если обновление вашего сервера не является для вас вариантом, почему бы и нет?

Я только что начал работать над проектом ASP.NET , который я надеюсь открыть с открытым исходным кодом, как только он достигнет подходящей стадии. В основном это будет библиотека, которую могут использовать существующие веб-сайты. Я предпочитаю поддерживать ASP.NET 2.0 через 3.5 , но мне было интересно, сколько людей я оставлю, не поддержав ASP.NET 1.1 ? Более конкретно, сколько людей все еще используют ASP.NET 1.1 , для которых ASP.NET 2.0/3.5 не является вариантом? Если обновление вашего сервера не является для вас вариантом, почему бы и нет?

У меня есть приложение ASP.NET 1.1, и я пытаюсь выяснить, почему при изменении значения ComboBox, которое используется для заполнения другого (отношение родитель-потомок), создаются две обратные связи.

Я проверял и проверял код, но не могу найти причину.

Вот оба стека вызовов, которые заканчиваются в page_load

Первая обратная (порожденных autopostback элемента управления ТЭН ComboBox по )

Стек обратного вызова http://www.juanformoso.com.ar/images/callstack1.jpg

Второй постбэк (это то, что я хочу найти, почему это происходит)

alt text http://www.juanformoso.com.ar/images/callstack2.jpg

Есть какие-нибудь предложения? Что я могу проверить?

На моей работе у меня есть сцепление из шести Windows services, за которое я отвечаю, написанное в C# 2003 году. Каждая из этих служб содержит таймер, который срабатывает каждую минуту или около того, где происходит большая часть их работы.

Моя проблема заключается в том, что по мере запуска этих служб они начинают потреблять все больше и больше времени CPU через каждую итерацию цикла, даже если для них нет никакой значимой работы (т. е. они просто бездельничают, просматривая базу данных для чего-то). Когда они запускаются, каждая служба использует в среднем (около) 2-3% из 4 CPUs, что нормально. Через 24 часа каждая служба будет потреблять весь процессор на протяжении всего цикла выполнения своего цикла.

Кто-нибудь может помочь? Я в недоумении, что может быть причиной этого. Наше текущее решение заключается в том, чтобы перезапускать сервисы один раз в день (они отключаются сами, затем скрипт видит, что они отключены, и перезапускает их примерно в 3 часа ночи). Но это не долгосрочное решение; меня беспокоит то, что, поскольку службы становятся более загруженными, перезапуска их один раз в день может быть недостаточно... но поскольку существует значительный штраф за запуск (все они используют NHibernate для доступа к данным), поскольку они становятся более загруженными, именно то, что мы не хотим делать, - это перезапускать их чаще.

@akmad: правда, это очень трудно.

1. Да, служба, запущенная изолированно, будет показывать тот же симптом с течением времени.
2. Нет, это не так, мы уже смотрели на это. Это может произойти в 10 утра, в 6 вечера или в середине ночи. Здесь нет никакой последовательности.
3. Мы делаем это, а они делают. Службы делают именно то, что они должны делать, и ничего больше.
4. К сожалению, это требует предвидения того, когда именно услуги будут исчерпаны CPUs, что происходит по непредсказуемому графику и никогда не бывает очень быстро... что делает вещи вдвойне трудными, потому что мой босс будет запускать и перезапускать их, когда у них начнутся проблемы, не думая о проблемах отладки.
5. Нет, они используют довольно стабильное количество RAM (ок. 60-80MB каждый, из 4 ГБ на машине).

Хорошие предложения, но rest заверил, что мы перепробовали все обычные способы устранения неполадок. Я надеюсь, что это проблема .NET, о которой кто-то может знать, и мы сможем работать над ее решением. Решение моего босса (которое я категорически не хочу реализовывать) состоит в том, чтобы поместить поле в базу данных, которая содержит несколько раз для перезапуска служб в течение дня, чтобы он мог устранить проблему и не думать о ней. Я Отчаянно ищу причину реальной проблемы, чтобы исправить ее, потому что это решение станет катастрофой примерно через шесть месяцев.

Эллис: у каждого из них своя функция. Один читает записи из базы данных Oracle где-то за пределами объекта; другой обрабатывает эти записи и передает файлы, принадлежащие этим записям, в нашу систему; третий проверяет эти файлы, чтобы убедиться, что они такие, какими мы их ожидаем; другой-это Служба технического обслуживания, которая постоянно проверяет такие вещи, как дисковое пространство (которого у нас достаточно) и опрашивает другие серверы, чтобы убедиться, что они живы; один работает только для того, чтобы убедиться, что все эти другие работают и выполняют свою работу, отслеживает и сообщает об ошибках и перезапускает все, что не удалось сохранить всю систему это происходит 24 часа в сутки.

Итак, если вы спрашиваете то, что я думаю, что вы спрашиваете, нет, нет ни одной общей вещи, которую делают все эти службы (кроме доступа к базе данных через NHibernate), на которую я могу указать как на потенциальную проблему. К сожалению, если это окажется фактической проблемой (что меня не сильно удивит), все это может быть испорчено-и я в конечном итоге перепишу все из них в простой SQL. Я надеюсь, что это проблема сборщика мусора или что-то более легкое для решения, чем NHibernate.

@Joshdan: никакого секрета. Как я уже сказал, мы испробовали все обычные способы устранения неполадок. Профилирование было бесполезным: профилировщик, который мы используем, не мог указать на какой-либо код, который фактически выполнялся, когда использование CPU было высоким. Эти службы были разорваны около месяца назад в поисках этой проблемы. Каждый раздел кода был проанализирован, чтобы попытаться выяснить, был ли наш код проблемой; я здесь не спрашиваю, потому что я не сделал свою домашнюю работу. Если бы это был простой случай, когда службы выполняли больше работы, чем ожидалось, это было бы поймано.

Проблема здесь заключается в том, что в большинстве случаев службы вообще ничего не делают, но все же умудряются потреблять 25% или более из четырех ядер CPU: они не находят никакой работы, выходят из своего цикла и ждут следующей итерации. Это должно, в буквальном смысле, почти не занимать времени CPU вообще.

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

День 1, 8 утра: авг. CPU использование приблизительно 3%
День 1, 6 вечера: авг. CPU использование приблизительно 8%
День 2, 7 утра: авг. CPU использование приблизительно 20%
День 2, 11 утра: авг. CPU использование приблизительно 30%

Рассмотрев все возможные мирские причины этого, я задал этот вопрос здесь, потому что я полагал (правильно, как оказалось), что получу более новаторские ответы (как Убигути) или указатели на вещи, о которых я не думал (как предложение Яна).

Так же происходит и Спайк CPU непосредственно перед таймером обратный вызов, в пределах обратного вызова таймера, или сразу после таймера обратный звонок?

Вы меня неправильно поняли. Это не Спайк. Если бы это было так, то не было бы никаких проблем; я могу справиться со спайками. Но это не так... использование CPU в целом растет. Даже когда служба ничего не делает, ожидая следующего удара таймера. Когда сервис запускается, все идет хорошо и спокойно, и график выглядит так, как вы и ожидали... как правило, использование 0%, с шипами до 10%, когда NHibernate попадает в базу данных или сервис выполняет какой-то тривиальный объем работы. Но это увеличивает до across-the-board 25% (больше, если я позволю ему зайти слишком далеко) использование во все времена, пока процесс запущен.

Это сделало предложение Йена логичной серебряной пулей (NHibernate делает много вещей, когда вы не смотрите). Увы, я реализовал его решение, но оно не возымело эффекта (у меня нет доказательств этого, но я действительно думаю, что это ухудшило ситуацию... среднее использование, кажется , теперь растет намного быстрее). Обратите внимание, что удаление NHibernate "sections" (как вы рекомендуете) нецелесообразно, так как это было бы уберите около 90% кода в сервисе, что позволило бы мне исключить таймер как проблему (которую я абсолютно намерен попробовать), но не может помочь мне исключить NHibernate как проблему, потому что если NHibernate вызывает это, то хитроумное исправление, которое реализовано (см. ниже), просто должно стать способом работы системы; мы настолько зависим от NHibernate для этого проекта, что PM просто не примет, что это вызывает неразрешимую структурную проблему.

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

Я не хочу, чтобы все так вышло. В настоящее время службы перезапускаются ежедневно (с возможностью ввода любого количества часов в день для их выключения и перезапуска), что исправляет проблему, но не может быть долгосрочным решением, как только они переходят на производственную машину и начинают загружаться. Проблемы не будут продолжаться, независимо от того, исправляю ли я их или PM поддерживает это ограничение на них. Очевидно, что я предпочел бы реализовать реальное исправление, но поскольку первоначальное тестирование не выявило никаких причин для этого, а службы уже были подробно рассмотрены, PM предпочел бы просто перезапустить их несколько раз, чем тратить больше времени на их исправление. Это полностью выходит из-под моего контроля и делает чудо, о котором вы говорили, более важным, чем оно было бы в противном случае.

Это чрезвычайно интригует (постольку как Вы доверяете своему профайлеру).

Я не. Но тогда это Windows services, написанные в .NET 1.1, запущенные на машине Windows 2000, развернутой хитрым сценарием Nant, использующим старую версию NHibernate для доступа к базе данных. На самом деле, я бы сказал, что мало чему доверяю на этой машине.

Мой код должен определить, как долго выполняется конкретный процесс. Но он продолжает отказывать с сообщением об ошибке отказано в доступе на запрос Process.StartTime . Это процесс, запущенный с учетными данными пользователя (т. е. не процесс с высокими привилегиями). Там явно есть параметр безопасности или параметр политики, или что- то , с чем мне нужно покрутить, чтобы исправить это, так как я не могу поверить, что свойство StartTime находится в рамках только для того, чтобы оно могло отказать 100% раз.

Поиск в Google показал, что я могу решить эту проблему, добавив пользователя, чьи учетные данные код запроса выполняется в группу "Performance Log Users". Однако на этой машине такой группы пользователей не существует.