AVK>Вот за попытку управлять руками памятью в серверном софте надо бить железной линейкой по пальцам :) Я понимаю еще на десктопе что то пооптимайзить, но на сервере! Это ж полный абзац будет если ты не дай бог где ошибешся.

Не надо. Мне ими еще работать.Никакого особого абзаца не случится. Ну закроется у одного из клиентов, т.н. документ(например счет или расх. накладная). Откроет и продолжит работать дальше. А управление памятью как раз и помогает обезопасить других пользователей. А вот оптимизировать сервер необходимо. Время реакции у пользователя должно быть минимальным при любых загрузках

МС>Возможно это так. К сожалению "тяжело" обсуждать эту тему ибо недостаточно
МС>информации об уже существующей системе.
МС>Имеет ли смысл ее переписывать? Какая у нее архитектура. Какие сервера БД
МС>и как используются. Итд Итд Итд

Если коротко. Многоуровневая архитектура, вытекающая из трехуровневой.
БД- ORACLE. К базе прямой доступ через Call Inerface.Переходники(а-ля ODBC) не используются. Медленные и нет всех возможностей.
Клиент который работает с системой за короткое время может сделать к базе 100 и даже 1000 запросов.
Компания Форс(занимаются поддержкой ORACLE в России) наше пользование БД по другому как извращением не называет.
Думаю что другие БД просто бы не выдержали такой подход. Microsoft SQL слил.
Свой язык логики. Свой язык запросов к базе. Свой дизайнер. Обмен через Window Socket.
А надо ли переписывать ? А хрен его знает. Может хочется что-то новенького или старею.

YL> Думаю что другие БД просто бы не выдержали такой подход.
YL> Свой язык логики. Свой язык запросов к базе. Свой дизайнер.
YL> Обмен через Window Socket.
YL> А надо ли переписывать ? А хрен его знает.

После "беглого" ознакомления с этой краткой информацией мое ИМХО, что
ничего сделать с этой системой не получится, тем более силами одного
человека. Перевод ее на .NET — это отдельный большой проект.
Как мне кажется единственная возможность попользовать .NET в
этой ситуации это выделить какое-то подмножество запросов
клиентского приложения и форвардить их на .NET (NewTechnology )
сервер, потом возвращать клиенту. Изврат конечно, но другого
способа поиграться в .NET в данной ситуации не вижу.

YL> Может хочется что-то новенького или старею.

Понимаю. Сам сейчас сижу с готовой системой писанной давным давно на плюсах.
Угнетает. Хочется "большого и светлого". Приходится урывать часы на работе
и тратить домашнее время для занятия любимым делом.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, YuraL, Вы писали:

YL>>Насколько я понял рвет он только по работе с памятью если присутствует одна большая куча ?
YL>>Ну тогда это не показатель. По моему мнению плюсы будут всегда быстрее этих языков(java, C#).

AVK>На куче мелких объектов дотнет уже быстрее плюсов, причем весьма заметно.

Ну, это ты перегнул. Я что-то не видел ни одного практического примера, где .NET был бы заметно быстрее. В лучшем случая .NET работает с такой же скоростью. А если в C++ использовать всякие техники для ускорения работы с маленькими объектами (например из Loki), то .NET вообще "курит".

Зато я видел как типичное серверное .NET приложение проводит от 30% до 80% процессорного времени в GC. Конечно, это само по себе ничего не говорит. Нужно сравнивать с типичным native приложением. Но такой факт имеет место, и к нему нужно привыкнуть.

Еше одна мысль. В C++ объекты не обязательно в хипе создавать, можно и на стеке. В .NET же, выбора особенно нет. А всем хорошо известно, что никакая техника выделения памяти в хипе не сравнится по скорости со стеком.

Еще один момент есть в GC. Когда памяти становится мало, и даже основная часть памяти выгружена в page file, GC может захотеть "проверить" всю память (и причем это может происходить периодически), что приведет к постоянному swapping'y. Я это тоже видел : приложение, которое обычно выполняется за одну минуту, при недостатке памяти работает 6 (!) часов.

МС>Понимаю. Сам сейчас сижу с готовой системой писанной давным давно на плюсах.
МС>Угнетает. Хочется "большого и светлого". Приходится урывать часы на работе
МС>и тратить домашнее время для занятия любимым делом.

Я конечно не один. А насчет угнетает и.т.д. это точно. Задолбало уже оптимизировать, улучшать и баги подчищать.

Здравствуйте, alexkro, Вы писали:

A>Здравствуйте, AndrewVK, Вы писали:

A>А всем хорошо известно, что никакая техника выделения памяти в
A>хипе не сравнится по скорости со стеком.

эта еще почему?

Здравствуйте, МихаилС, Вы писали:

МС>Здравствуйте, alexkro, Вы писали:

A>>Здравствуйте, AndrewVK, Вы писали:

A>>А всем хорошо известно, что никакая техника выделения памяти в
A>>хипе не сравнится по скорости со стеком.

МС>эта еще почему?

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

Здравствуйте, alexkro, Вы писали:

A>>>А всем хорошо известно, что никакая техника выделения памяти в
A>>>хипе не сравнится по скорости со стеком.

МС>>эта еще почему?

A>Да потому что на стеке выделение и освобождение памяти тривиально.

Читайте того же Рихтера. В CLR managed heap работает так же как стек.
Есть указатель на границу памяти и меняется только он.

Здравствуйте, МихаилС, Вы писали:

МС>Здравствуйте, alexkro, Вы писали:

A>>>>А всем хорошо известно, что никакая техника выделения памяти в
A>>>>хипе не сравнится по скорости со стеком.

МС>>>эта еще почему?

A>>Да потому что на стеке выделение и освобождение памяти тривиально.

МС>Читайте того же Рихтера. В CLR managed heap работает так же как стек.
МС>Есть указатель на границу памяти и меняется только он.

Да, идея выделения памяти в .NET такая. Но никто не говорит, что реализация также проста. А освобождение памяти в .NET вообще очень далеко от тривиальности.

A> Да, идея выделения памяти в .NET такая.
A> Но никто не говорит, что реализация также проста.
A> А освобождение памяти в .NET вообще очень далеко от тривиальности.

Изначально речь шла о выделении памяти в хипе и в стеке.
Про реализацию ничего говорить не буду так как не знаю,
но: 1. над этими вещами работают не дураки, 2. механизмы
вне всякого сомнения будут совершенствоваться, 3. мощностя
камней растут как на дрожжах.

Отступая от темы производительности хипА:
Очень важный момент состоит в том, что если речь не идет о
драйверах, кодеках и т.п. пиковая производительность некоторого
участка кода не является критичной. С современными мощностями
и объемами оверхед на проведение некоторых действий
(тем более таких важных как корректное управление памятью)
вполне допустим.
Рулезы, которые предлагает .NET настолько повышают
другие показатели такие как: надежность, скорость разработки,
легкость развертывания, простота развития итд, что с некоторой
потерей производительности по сравнению с "идеальной системой,
написаной идеальным программистом на плюсах или ассемблере" можно
вполне смириться.
Если объемы данных/количество операций велико, то можно сделать
вывод, что фирма может поставить на сервер лишний гиг памяти или
дополнительный процессор.
Кроме того сейчас очень "модно" тащить все в память, например,
восстанавливать объекты БД и хранить их на протяжении всего жизненного
цикла приложения в памяти. Подобные подходы могут посадить все что
угодно и .NET, и C++, и все остальное (всегда есть объем с которым
не справится система).
При правильном подходе многих проблем с производительностью может
не возникать и на более медленных чем .NET вещах. Не даром в какой-то
статье разработчика из MS (помоему про X#) подчеркивалось, что сейчас
программисты слишком злоупотребляют объектно-ориентированным
подходом применяя его подчас где он совершенно не нужен, так для
обработки данных очень часто не нужно их объектного представления в памяти.

Все пора прекращать флейм, а то модератор сейчас пристрелит...

Здравствуйте, YuraL, Вы писали:

YL>Не надо. Мне ими еще работать.Никакого особого абзаца не случится. Ну закроется у одного из клиентов, т.н. документ(например счет или расх. накладная). Откроет и продолжит работать дальше.

Не, фиг там. Если у тебя на сервере потечет память то через некоторое время твой сервер просто встанет.

YL> А управление памятью как раз и помогает обезопасить других пользователей.

Какую то ты ерунду говоришь. Ручное управление памятью никогда ни к чему хорошему не приведет. Каким образом это обезопасит пользователей мне непонятно. Или ты хочешь на каждого пользователя свой хип? Ну так тогда домены приложений это именно то что нужно. В домене ты изолируешь и обезопасишь не только память.

YL>А вот оптимизировать сервер необходимо. Время реакции у пользователя должно быть минимальным при любых загрузках

Вот как раз с точки зрения минимизации времени отклика сделать GC крайне сложно. Ты просто сделай два тестика — один на дотнете, а другой на плюсах и посмотри что у тебя получится.

Здравствуйте, alexkro, Вы писали:

A>Ну, это ты перегнул. Я что-то не видел ни одного практического примера, где .NET был бы заметно быстрее. В лучшем случая .NET работает с такой же скоростью. А если в C++ использовать всякие техники для ускорения работы с маленькими объектами (например из Loki), то .NET вообще "курит".

Знаешь в чем проблема традиционного хипа? В том что он удаляет сразу же, тормозя алгоритм, увеличивая время доступа и фрагментацию хипа. GC же просто не запускается в это время, а потом, при простое, он запускается и убирает.

A>Зато я видел как типичное серверное .NET приложение проводит от 30% до 80% процессорного времени в GC. Конечно, это само по себе ничего не говорит. Нужно сравнивать с типичным native приложением. Но такой факт имеет место, и к нему нужно привыкнуть.

Не надо к нему привыкать — явно кривота в приложении. Во первых — по моим экспериментам сам по себе GC запускается очень неохотно. Во вторых я видел EJB сервера с тем же GC под немаленькой нагрузкой — никакого постоянного запуска сборщика не наблюдалось. Видимо в этом приложении по поводу и без него ручками постоянно вызывается GC.Collect()

A>Еше одна мысль. В C++ объекты не обязательно в хипе создавать, можно и на стеке. В .NET же, выбора особенно нет. А всем хорошо известно, что никакая техника выделения памяти в хипе не сравнится по скорости со стеком.

Хинт: value типы создаются в стеке.

A>Еще один момент есть в GC. Когда памяти становится мало, и даже основная часть памяти выгружена в page file, GC может захотеть "проверить" всю память (и причем это может происходить периодически), что приведет к постоянному swapping'y. Я это тоже видел : приложение, которое обычно выполняется за одну минуту, при недостатке памяти работает 6 (!) часов.

Опять явная кривизна приложения — специально запускал янус на 32М. Тормозит конечно, но никаких часов не наблюдается.

Здравствуйте, YuraL, Вы писали:

AVK>>Именно по скорости.

YL>Не верю. За счет чего ?

За счет того что он как правило вобще не освобождает ничего сразу.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, alexkro, Вы писали:

A>>Ну, это ты перегнул. Я что-то не видел ни одного практического примера, где .NET был бы заметно быстрее. В лучшем случая .NET работает с такой же скоростью. А если в C++ использовать всякие техники для ускорения работы с маленькими объектами (например из Loki), то .NET вообще "курит".

AVK>Знаешь в чем проблема традиционного хипа? В том что он удаляет сразу же, тормозя алгоритм, увеличивая время доступа и фрагментацию хипа. GC же просто не запускается в это время, а потом, при простое, он запускается и убирает.

В теории. На практике же проблеммы фрагментации не так страшны, как их малюют, а GC не такой эффективный.

A>>Зато я видел как типичное серверное .NET приложение проводит от 30% до 80% процессорного времени в GC. Конечно, это само по себе ничего не говорит. Нужно сравнивать с типичным native приложением. Но такой факт имеет место, и к нему нужно привыкнуть.

AVK>Не надо к нему привыкать — явно кривота в приложении. Во первых — по моим экспериментам сам по себе GC запускается очень неохотно. Во вторых я видел EJB сервера с тем же GC под немаленькой нагрузкой — никакого постоянного запуска сборщика не наблюдалось. Видимо в этом приложении по поводу и без него ручками постоянно вызывается GC.Collect()

Не правильно. Никаких GC.Collect() там и в помине не было.

A>>Еше одна мысль. В C++ объекты не обязательно в хипе создавать, можно и на стеке. В .NET же, выбора особенно нет. А всем хорошо известно, что никакая техника выделения памяти в хипе не сравнится по скорости со стеком.

AVK>Хинт: value типы создаются в стеке.

Я думаю, ты меня не понял. Попробуй создать System.String на стеке. Вот, вот. А в C++ объекты любых классов на стеке можно сделать.

A>>Еще один момент есть в GC. Когда памяти становится мало, и даже основная часть памяти выгружена в page file, GC может захотеть "проверить" всю память (и причем это может происходить периодически), что приведет к постоянному swapping'y. Я это тоже видел : приложение, которое обычно выполняется за одну минуту, при недостатке памяти работает 6 (!) часов.

AVK>Опять явная кривизна приложения — специально запускал янус на 32М. Тормозит конечно, но никаких часов не наблюдается.

Я запускал Word XP, ограничив его Working Set до 5MB — работает безо всяких тормозов. А с янусом такое можно сделать?

Мне так кажется, AndrewVK, что у тебя слишком радужные представления о GC. У GC есть свои приемущества, не спорю. Но и проблем тоже хватает.

Здравствуйте, alexkro, Вы писали:

AVK>>Знаешь в чем проблема традиционного хипа? В том что он удаляет сразу же, тормозя алгоритм, увеличивая время доступа и фрагментацию хипа. GC же просто не запускается в это время, а потом, при простое, он запускается и убирает.

A>В теории. На практике же проблеммы фрагментации не так страшны, как их малюют, а GC не такой эффективный.

GC в несколько раз эффективнее как раз там, где память интенсивно нарезается мелкими кусочками. Вот результаты теста (подробности и исходники теста здесь

Автор(ы): Игорь Ткачев
Дата: 06.12.2002
Алгоритм работы сборщика мусора (garbage collector, далее просто GC), являющегося частью CLR, подробно описан в книге Джефри Рихтера (Jeffrey Richter) «Applied Microsoft .NET Framework Programming». Мы не будем приводить здесь столь же подробное описание этого алгоритма, но обязательно остановимся на некоторых ключевых моментах.

)



Обрати внимание на первую половину графика, выигрыш GC в 3-4 раза. Лидер (QH) — это как раз тот самый случай ручной оптимизации хипа на C++. Только вопрос какой ценой даётся это лидерство.

A>>>Зато я видел как типичное серверное .NET приложение проводит от 30% до 80% процессорного времени в GC. Конечно, это само по себе ничего не говорит. Нужно сравнивать с типичным native приложением. Но такой факт имеет место, и к нему нужно привыкнуть.

У меня апп-сервера дышат ровно и вообще пышут здоровьем (тьфу-тьфу-тьфу-три-раза) С комом были проблемы, то лики, то ссылки кто-нибудь не освободит...

AVK>>Хинт: value типы создаются в стеке.

A>Я думаю, ты меня не понял. Попробуй создать System.String на стеке. Вот, вот. А в C++ объекты любых классов на стеке можно сделать.

И CString тоже на стеке, и std::string?

A>Я запускал Word XP, ограничив его Working Set до 5MB — работает безо всяких тормозов.

А документ какой-нибудь ты в него загружал?

A>Мне так кажется, AndrewVK, что у тебя слишком радужные представления о GC. У GC есть свои приемущества, не спорю. Но и проблем тоже хватает.

Проблема у GC одна — если ты забъёшь память неиспользуемыми объектами, на которые где-то болтаются ссылки (впрочем, проблема будет не только у GC). Подобные глюки были замечены. Например на нашем сайте. ASP.NET одно время периодически перегружалась после того как пожирала неимоверное количество памяти. Оказалось, что это из-за глюка в Regex'ах. По всей видимости, где-то оставались ссылки на отработанные объекты. После соответствующей модификации кода глюки исчезли.

Здравствуйте, alexkro, Вы писали:

AVK>>Знаешь в чем проблема традиционного хипа? В том что он удаляет сразу же, тормозя алгоритм, увеличивая время доступа и фрагментацию хипа. GC же просто не запускается в это время, а потом, при простое, он запускается и убирает.

A>В теории. На практике же проблеммы фрагментации не так страшны, как их малюют, а GC не такой эффективный.

Нормальный GC, проверено как раз на практике. По крайней мере страшных тормозов при огромном количестве мелких объектов , как это бывало в обычном хипе, нет.

A>Не правильно. Никаких GC.Collect() там и в помине не было.

Тогда не понимаю почему там GC работал постоянно. Может памяти совсем мало было?

A>Я думаю, ты меня не понял. Попробуй создать System.String на стеке. Вот, вот. А в C++ объекты любых классов на стеке можно сделать.

Ага, а в СОМ ты стринг на стеке сможешь передать?

AVK>>Опять явная кривизна приложения — специально запускал янус на 32М. Тормозит конечно, но никаких часов не наблюдается.

A>Я запускал Word XP, ограничив его Working Set до 5MB — работает безо всяких тормозов. А с янусом такое можно сделать?

Позволь узнать — ты какого размера документы туда грузил? Загрузи мег на 15 — вот после этого и сравнивай. Хотя конечно расход у GC памяти повышенный, это давно известно. Плата за удобство.

A>Мне так кажется, AndrewVK, что у тебя слишком радужные представления о GC. У GC есть свои приемущества, не спорю. Но и проблем тоже хватает.

Нормальные у меня представления. Все же год писал на джаве, а теперь уже почти год на дотнете. Так что думаю опыта мне хватает чтобы оценить его возможности.

Здравствуйте, IT, Вы писали:

IT>Обрати внимание на первую половину графика, выигрыш GC в 3-4 раза. Лидер (QH) — это как раз тот самый случай ручной оптимизации хипа на C++. Только вопрос какой ценой даётся это лидерство.

Печальный тест для GC. QuickHeap — это, кстати, то, что очень легко получается. Такие наработки уже есть и в большом количестве.

A>>>>Зато я видел как типичное серверное .NET приложение проводит от 30% до 80% процессорного времени в GC. Конечно, это само по себе ничего не говорит. Нужно сравнивать с типичным native приложением. Но такой факт имеет место, и к нему нужно привыкнуть.

IT>У меня апп-сервера дышат ровно и вообще пышут здоровьем (тьфу-тьфу-тьфу-три-раза) С комом были проблемы, то лики, то ссылки кто-нибудь не освободит...

Ради экперемента понаблюдай за perf counter, который показывает время проведенное в GC, при нагруженном сервере.

AVK>>>Хинт: value типы создаются в стеке.

A>>Я думаю, ты меня не понял. Попробуй создать System.String на стеке. Вот, вот. А в C++ объекты любых классов на стеке можно сделать.

IT>И CString тоже на стеке, и std::string?

А почему бы и нет. std::string между прочем для маленьких строк в хипе память не выделяет.

Дело не в конкретных классах, а в возможности.

A>>Я запускал Word XP, ограничив его Working Set до 5MB — работает безо всяких тормозов.

IT>А документ какой-нибудь ты в него загружал?

Сам Word при этом отнимал 20MB, 15 из которых были в page файле.

A>>Мне так кажется, AndrewVK, что у тебя слишком радужные представления о GC. У GC есть свои приемущества, не спорю. Но и проблем тоже хватает.

IT>Проблема у GC одна — если ты забъёшь память неиспользуемыми объектами, на которые где-то болтаются ссылки (впрочем, проблема будет не только у GC). Подобные глюки были замечены. Например на нашем сайте. ASP.NET одно время периодически перегружалась после того как пожирала неимоверное количество памяти. Оказалось, что это из-за глюка в Regex'ах. По всей видимости, где-то оставались ссылки на отработанные объекты. После соответствующей модификации кода глюки исчезли.

Хороший пример: memory leaks в .NET тоже возможны. Интересно узнать, а как вы все-таки обнаружили причину?

AVK>Не, фиг там. Если у тебя на сервере потечет память то через некоторое время твой сервер просто встанет.
1.Практика показывает обратное. Ты сильно сгущаешь краски.
2. Rational Rose написали отличные ребята( это я об утечках памяти).


YL>> А управление памятью как раз и помогает обезопасить других пользователей.

AVK>Какую то ты ерунду говоришь. Ручное управление памятью никогда ни к чему хорошему не приведет. Каким образом это обезопасит пользователей мне непонятно. Или ты хочешь на каждого пользователя свой хип? Ну так тогда домены приложений это именно то что нужно. В домене ты изолируешь и обезопасишь не только память.

Правильно, но не совсем. Не на пользователя а на соединение на сервере приложения. И когда пользователь закрывает соединение разрушается heap. Т.е. никаких утечек не происходит !!!

YL>>А вот оптимизировать сервер необходимо. Время реакции у пользователя должно быть минимальным при любых загрузках

AVK>Вот как раз с точки зрения минимизации времени отклика сделать GC крайне сложно. Ты просто сделай два тестика — один на дотнете, а другой на плюсах и посмотри что у тебя получится.

Да делал уже. На С++ и С#. Для NETa последствия хреновые. Это говорит о том, что писать на NET сервер приложения нецелесобразно. Да это будет надежно, можно быстро локализовывать ошибки, но это будет вселенский тормоз.
Заказчики не поймут и не одобрят. Мы ведь с ребятами делаем коммерческий продукт. С этого и живем.
С уважением, Юрий

Здравствуйте, YuraL, Вы писали:

AVK>>Не, фиг там. Если у тебя на сервере потечет память то через некоторое время твой сервер просто встанет.
YL>1.Практика показывает обратное. Ты сильно сгущаешь краски.

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

YL>2. Rational Rose написали отличные ребята( это я об утечках памяти).

Роза то тебе чем поможет? Нет я понимаю что сейчас будут мне рассказывать про смарт-поинтеры, правильное проектирование, баундс чекеры, но это все полумеры. Я при написании сервера хочу заниматься его логикой, а не распределением памяти. В обычном сервере на джаве или дотнете сплошь и рядом отложенное создание, кеширование, пулинг и прочая. Если попытаться написать подобным образом на плюсах, да еще если ручками хип делать, то отловить в ней что то это полный абзац. А когда к этому добаляется еще СОМ то все становиться просто прекрасно. Ощущение такое что программа живет своей жизнью, потому как единого цикла ее работы и порядка создания объектов с ходу определить не удастся. А GC подобное вполне позволяет без особого напряга, потому как я память выделил, а когда и кто ее будет освобождать мне по барабану, я знаю что она гарантированно убьется.

YL>Правильно, но не совсем. Не на пользователя а на соединение на сервере приложения. И когда пользователь закрывает соединение разрушается heap. Т.е. никаких утечек не происходит !!!

Тогда домен самое оно. Заодно можно исключить выполнение привилегированного кода пользователем.

AVK>>Вот как раз с точки зрения минимизации времени отклика сделать GC крайне сложно. Ты просто сделай два тестика — один на дотнете, а другой на плюсах и посмотри что у тебя получится.

YL>Да делал уже. На С++ и С#. Для NETa последствия хреновые.

У меня почему то картинка обратная (да не только у меня, IT тебе ссылочку привел)

YL>Это говорит о том, что писать на NET сервер приложения нецелесобразно.

Именно для серверов приложений дотнет прежде всего и делался. Сейчас в мире тяжелые сервера пишут как правило на джаве.

YL> Да это будет надежно, можно быстро локализовывать ошибки, но это будет вселенский тормоз.

Железка дешевле софта.

YL>Заказчики не поймут и не одобрят. Мы ведь с ребятами делаем коммерческий продукт. С этого и живем.

Я тут как бы на текущей работе прежде всего как раз такой заказчик а не программер. Так вот — я тебе честно скажу — на тормоза мне плевать, особенно на такие какие будут из за разных механизмов выделения памяти (можешь пообщаться с Владом, он тебе расскажет насколько изменилось быстродействие, когда он вместо стандартного использовал quick heap). А вот если в сервере будут месяцами жить утечки то в лес такой сервер. Если для изменения бизнес-логики мне придется писать код на С++ то тоже в лес такой сервер.

Здравствуйте, IT, Вы писали:

IT>....[skipped].... Например на нашем сайте. ASP.NET одно время периодически перегружалась после того как пожирала неимоверное количество памяти. Оказалось, что это из-за глюка в Regex'ах. По всей видимости, где-то оставались ссылки на отработанные объекты. После соответствующей модификации кода глюки исчезли.

а можно по подробнее что за глюки такие (извините за отступ от темы)