отладка в VW
victor metelitsa
сервере внутри девелоперского имиджа (с тем, чтобы, когда набор её фич
стабилизируется, "отрубить голову" и пускать уже как сервис, а сейчас
она законнекчена к Store и я загружаю новый версии на ходу по мере
необходимости).
Выполнена она как веб-приложение на VW 7.3, в виде сервлета,
используются DB2ThapiEXDI и Glorp for DB2 (большое спасибо Антону),
Store for Interbase (спасибо ему же).
Раз в несколько дней моя прикладнушка дохнет на ровном месте, не
оставляя ни следа. Пару раз я успевал заметить, как это происходит.
Прежде всего подскакивает потребление памяти (до нескольких сотен
мегабайтов) и загрузка процессора, это продолжается какое-то время
(десятки секунд), затем прикладнушка тихо помирает.
Я не думаю, что это ошибки в моем коде - хотя бы потому, что она
помирала бы по-другому, не так тихо. Отладочная версия VM 7.3 во время
работы прикладнушки выдавала в консоль письмена типа
Assert fail @ 1570 in mman\mmScavenge.c ephemeronListIsOk()
Assert fail @ 2975 in mman\mmScavenge.c prevEntry == tailOfEphemeronList
Assert fail @ 1526 in mman\mmScavenge.c ephemeronListIsOk()
Assert fail @ 2975 in mman\mmScavenge.c prevEntry == tailOfEphemeronList
Assert fail @ 1570 in mman\mmScavenge.c ephemeronListIsOk()
Assert fail @ 1778 in mman\mmScavenge.c lastScannedOnEphemeronList ==
tailOfEphemeronList
Assert fail @ 2975 in mman\mmScavenge.c prevEntry == tailOfEphemeronList
Assert fail @ 1920 in mman\mmScavenge.c ephemeronListIsOk()
Assert fail @ 2975 in mman\mmScavenge.c prevEntry == tailOfEphemeronList
Assert fail @ 1570 in mman\mmScavenge.c ephemeronListIsOk()
Assert fail @ 2975 in mman\mmScavenge.c prevEntry == tailOfEphemeronList
Assert fail @ 1526 in mman\mmScavenge.c ephemeronListIsOk()
Assert fail @ 2975 in mman\mmScavenge.c prevEntry == tailOfEphemeronList
Assert fail @ 1570 in mman\mmScavenge.c ephemeronListIsOk()
Assert fail @ 1778 in mman\mmScavenge.c lastScannedOnEphemeronList ==
tailOfEphemeronList
что не мешало программе работать.
7.3.1 на консоль ничего не выдает, но падения продолжаются.
У меня всего две идеи.
Первая -заменить DB2ThapiEXDI на DB2EXDI.
Вторая - вернуться на VAST (благо, сервлеты есть и там, и Glorp я в свое
время переносил).
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Andrei N. Sobchuck
vm> Раз в несколько дней моя прикладнушка дохнет на ровном месте, не
vm> оставляя ни следа. Пару раз я успевал заметить, как это происходит.
vm> Прежде всего подскакивает потребление памяти (до нескольких сотен
vm> мегабайтов) и загрузка процессора, это продолжается какое-то время
vm> (десятки секунд), затем прикладнушка тихо помирает.
Первое (маловероятное) попробуй загрузить StackOverflow
http://www.smalltalk.ru/2005/01/vw-stackoverflow-shiffmantimeout.html
Единственное, что при заполнении памяти прикладнуха помирает не тихо.
vm> Первая -заменить DB2ThapiEXDI на DB2EXDI.
А вот это уже ближе к телу. Я гдето видел, писали что-то про проблемы
стабильности (но, afair, не DB2, а Interbase EXDI, не помню точно).
У ThapiEXDI вызовы нижележащей библиотеки не блокирующие
и, соответсвенно, во время вызова может произойти компактизация памяти.
Можно попробовать порешать, как описано в http://tinyurl.com/cxljw
--
Andrei N.Sobchuck
JabberID: and...@jabber.ru. ICQ UIN: 46466235.
victor metelitsa
приложение - в подклассе SingleThreadModelServlet
doGet и doPost вызывают doService.
doService - это
[| type |
self writeLog: 'begin'.
timerMicroseconds := Time microsecondClock.
self initGlorpConnection.
type := request getParameter: 'type'.
type isNil ifTrue: [type := 'ShowFirstPage'].
self checkAutorization
ifFalse: [type = 'Login' ifFalse: [
type := 'AutorizationRequest']].
session locale: (Locale named: Locale preferredLocaleName).
self perform: ('xxx' , type) asSymbol
]
ensure: [self closeGlorpConnection].
self writeLog: 'end'.
******************
Ничего выдающегося. "self writeLog:" вызывается дважды, с идеей, что,
когда и если что-то случится при построении страницы, с суффиксом
'begin' файл будет, а 'end' нет, и это покажет мне, на какой странице с
какими параметрами появляется проблема.
Связь с базой данных осуществляется "женским способом" - connect в
начале страницы и disconnect в конце - это параноидальная перестраховка
от накопления мусора (благо, нагрузка на сервер небольшая).
Отмечу, что строку
session locale: (Locale named: Locale preferredLocaleName).
мне пришлось поставить в 7.3.1
******************
writeLog: nameSuffix
| fileName file |
(fileName := (Timestamp now asMicroseconds printString , '-' ,
nameSuffix , '.log')
asFilename) withEncoding: #cp866.
file := fileName writeStream.
file
nextPutAll: Timestamp now printString;
cr.
file
nextPutAll: 'Среда запроса:';
cr;
cr.
request webRequest serverEnvironment keys asSortedCollection do:
[
:key |
file
tab;
nextPutAll: key;
nextPutAll: '=';
nextPutAll: (request webRequest serverEnvironment at: key);
cr.
].
file
cr;
nextPutAll: 'Переменные запросв:';
cr;
cr.
request getParameterNames asSortedCollection do:
[
:eachName |
file
tab;
nextPutAll: eachName;
nextPutAll: ' = ';
nextPutAll: (request getParameter: eachName);
cr.
].
file
cr;
nextPutAll: 'Переменные сеанса:';
cr;
cr.
session attributeNames asSortedCollection do:
[
:key |
file
tab;
nextPutAll: key;
nextPutAll: '=';
nextPutAll: (session attribute: key) printString;
cr.
].
file close.
******************
initGlorpConnection
| login |
login := (Glorp.Login new) database: Glorp.DB2Platform new;
username: '**********';
password: '**********';
connectString: '**********'.
glorpSession := Glorp.GlorpSession new.
glorpSession initializeCache.
glorpSession system: (FfpPlusDescriptorSystem forPlatform: login
database).
glorpSession accessor: (glorpAccessor := Glorp.DatabaseAccessor
forLogin: login).
glorpAccessor login.
glorpAccessor logging: false.
******************
closeGlorpConnection
glorpAccessor logout.
******************
И что я выяснил? Ничего, чтобы понять, как с этим бороться.
1. В VW 7.3.1 перед крэшем подскока в потреблении памяти я уже не видел
- умирает тихо и сразу.
2. Не могу воспроизвести проблему по желанию.
2.1. WebStress threaded EXDI, на нескольких URL, несколькими десятками
одновременных запросах в течение нескольких часов подряд (запускает
порцию в несколько десятков штук и ждет, пока они все не выполнятся, и
так в цикле - у имиджа подскакивает потребление памяти мег до 200, у
СУБД видно много коннектов) не смог уронить.
2.2 На той же самой домашней машинке я уронил тот же имидж "вручную"
дважды за полчаса. "Нечетных" (-begin есть, а -end нет) логов не было,
то есть крэш происходил перед
self writeLog: 'begin'.
Страница, при попытке отображения которой происходил крэш, после
перезапуска имиджа отображалась нормально.
Andrei N. Sobchuck
vm> 2. Не могу воспроизвести проблему по желанию.
vm> 2.1. WebStress threaded EXDI, на нескольких URL, несколькими десятками
vm> одновременных запросах в течение нескольких часов подряд (запускает
vm> порцию в несколько десятков штук и ждет, пока они все не выполнятся, и
vm> так в цикле - у имиджа подскакивает потребление памяти мег до 200, у
vm> СУБД видно много коннектов) не смог уронить.
vm> 2.2 На той же самой домашней машинке я уронил тот же имидж "вручную"
vm> дважды за полчаса. "Нечетных" (-begin есть, а -end нет) логов не было,
vm> то есть крэш происходил перед
vm> self writeLog: 'begin'.
vm> Страница, при попытке отображения которой происходил крэш, после
vm> перезапуска имиджа отображалась нормально.
Самый надёжный способ - взять внешний отладчик и посмотреть
где оно пропадает.
А так... Я бы попробовал использовать не-тредовый EXDI, потом ODBC
вместо EXDI. Дальше не знаю. :( Кстати, у тебя в образе
какая временная зона стоит?
Andrei N. Sobchuck
vm> то есть крэш происходил перед
vm> self writeLog: 'begin'.
Что есть #writeLog:? Там внутри #flush есть? Какие лимиты на память?
--
Andrei N.Sobchuck
JabberID: and...@jabber.ru. ICQ UIN: 46466235.
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
victor metelitsa
2. Не могу воспроизвести проблему по желанию.
2.1. WebStress threaded EXDI, на нескольких URL, несколькими десятками
одновременных запросах в течение нескольких часов подряд (запускает
порцию в несколько десятков штук и ждет, пока они все не выполнятся, и
так в цикле - у имиджа подскакивает потребление памяти мег до 200, у
СУБД видно много коннектов) не смог уронить.
2.2 На той же самой домашней машинке я уронил тот же имидж "вручную"
дважды за полчаса. "Нечетных" (-begin есть, а -end нет) логов не было,
то есть крэш происходил перед
self writeLog: 'begin'.
Страница, при попытке отображения которой происходил крэш, после
перезапуска имиджа отображалась нормально.