| cx_Oracle в нестабильной сетевой среде |
[Apr. 15th, 2012|06:48 pm]
Denis
|
Очень разочаровывает.
Нестабильная сетевая среда заключается всего лишь в VPN соединении, которое подвержено обрывам не только из-за возможных работ на сетевом оборудовании двух организаций и их провайдеров, но и не очень высокой стабильностью vpnc, который коннектится к cisco. В результате сбоя vpnc переподключается, сетевое соединение с ораклом рвется, а скрипт, ожидающий результатов выполнения запроса на несколько часов, зависает навсегда.
Стремительно уменьшающееся по весне количество сотрудников как-то это ни странно заставляет заниматься программированием в сторону автоматизации работы, и обрабатывать такие зависания по идее должно быть просто. Изначально идея была в том, чтобы в фоне проверять, жив ли коннект, и если не жив, то нормально это обрабатывать. У cx_Oracle есть даже какой-то ping(), который в моем случае всегда говорит None, но это в теории как бы не смертельно, можно же вполне сделать в том же коннекте какой-нибудь select sysdate from dual с таймаутом выполнения. Практика показала что да, сделать конечно можно, но результат вернется через несколько часов, после выполнения первого запроса. Поэтому идея определять жив ли коннект умерла довольно быстро, дальше начались просто таймауты. И с некоторыми странностями они даже получились, можно сделать connection.cancel(), в результате чего прерывается выполнение этого длинного запроса, а после этого connection.close() все доводит до конца. Т.е. все работает, не смотря на то, что интернете есть несколько тем про несовершенство ОС Windows для таких задач, но самое удивительное, что работает это только как раз в windows, при выполнении тех же действий в linux все традиционно виснет. Глубоко удивительно, причем подозревал что это возможно из-за XE клиента на тестовом сервере, но на нетестовом с 11м клиентом все ровно то же самое.
Конечно вероятно можно как-то хитро убивать процесс из самого процесса, ну или вообще кроме threading использовать еще и multiprocessing, там оно точно убивается, но это решение только половины проблемы, которое и так решается киллом по крону, запрос при этом продолжает выполняться в оракле, замедляя повторные попытки получить нужные данные.
Поневоле начинаешь задумываться о том, что может лучше попробовать какую-нибудь джаву.
UPD: Все же сделать четверть из того что нужно кажется возможно, с threaded=False connection.cancel() вдруг начал работать и в линуксе тоже, но в windows он прерывает текущий longop, а в linux прерывает выполнение следующих, текущий продолжает выполняться, после попытки connection.close() и там и там все зависает, но в линуксе это относительно просто решается самоубийством скрипта через os.kill(os.getpid(), signal.SIGTERM), а вот в windows убить самого себя оказывается чуть сложнее, но не принципиально. |
|
|
| (no subject) |
[Dec. 28th, 2011|10:53 pm]
Denis
|
|
И кстати про Mercurial и Word, при детальном анализе оказалось что никакой заслуги меркуриала, хотя точнее TortoiseHg, в работе с вордовыми документами нет, работает он ровно при помощи тех же js скриптов из TortoiseSVN, просто грамотно утащенных и подключенных. При желании не так сложно пишется плагин, который будет делать примерно тоже самое, но счастья в этом похоже тоже нет. Кажется скрепя сердце нужно признать что SharePoint позволяет осуществлять совместную правку документов в более удобном виде, хотя других положительных моментов в нем найти не удалось, но и в достаточной мере отрицательных тоже. Но вообще похоже что из-за изменившейся политической ситуации вопрос совместной правки и версионности документов стремительно теряет свою актуальность и воспользоваться SharePoint’ом в очередной раз не придется. |
|
|
| python 2.7 в rhel 5 |
[Dec. 28th, 2011|10:36 pm]
Denis
|
Под конец второго года регулярных ругательств в адрес компании Red Hat за неприлично древнюю версию python в их продуктах, в результате чего при выкладывании написанного на самый главный продакшн сервер достаточно часто приходилось идти назад и переписывать куски кода для совместимости с 2.4, вдруг обнаружилось что благодаря компании ActiveState страдать вовсе не обязательно, можно даже без наличия рутовых прав легко поставить откомпилированные бинарники достаточно свежей версии диалекта в виде ActivePython, при этом вообще никак не затрагивая систему. Единственный неприятный момент это неработающие кнопки стрелок, которые ActiveState предлагает лечить выполнением команды pypm install readline, которая конечно требует интернета, и которого конечно на этом злостном продакшене совсем нет. Хотя даже при наличии интернета, необходимый readline.so все равно желает ставится в глубину домашнего каталога пользователя, от имени которого был запущен pypm, и другие юзеры оказываются лишены этого маленького счастья. Но это в принципе тоже достаточно просто лечится созданием общего каталога для всяких модулей и прописыванием его в PYTHONPATH. И даже без интернета можно ставить то что нужно, скачав его предварительно с pypm-free.activestate.com, и указав pypm ключ -n, он ругается на JSON, но установку выполняет. Даже удивительно сколько времени и нервов было потрачено зря, нужно было всего лишь просто усерднее гуглить. |
|
|
| Mercurial |
[Nov. 2nd, 2011|10:35 pm]
Denis
|
Насмотревшись на кучу графиков о том, как стремительно растет популярность mercurial и как жалко на фоне его и git выглядит bazaar, решил в очередной раз попробовать, скачал свежий tortoisehg и начал сразу с самого сложного – документа ворд с русским именем.
TortoiseHG с самого начала приятно удивил богатством всего подряд на одном экране, а также наличием kdiff3, который с виду прямо из коробки умеет сравнивать base, other и this, и таким непривычным для базара счастьем как docdiff, вот прямо щелкаешь мышкой и он тебе запускает ворд, который отображает все изменения. Но дальше почему-то вышел полный провал, потыкав во все подряд так и не понял как сделать бранч, это при том что в BzrExplorer , который мне все больше не нравится, все это делается предельно элементарно. По поводу бранчей помог гугл, нашлась инструкция с картинками, и после перевода TortoiseHG на английский все даже получилось, хотя последовательность действий выглядит диковато, при том что в командной строке судя по той же инструкции все предельно просто и логично. А вот дальше я попытался утащить полученное на линукс и прямо сразу получил там "abort: requirement 'dotencode' not supported!" , все это судя по гуглу конечно тоже лечится, но чтобы долго не страдать, просто пошел и посмотрел что у репозитория внутри, а внутри у него по-прежнему кодировка win1251 и поэтому дальше можно просто не продолжать. Вроде бы конечно есть патч который частично решает эту проблему, но на улице вот-вот закончится 2011 год, а кроссплатформенный софт все еще страдает настолько откровенной глупостью, что серьезно воспринимать его уже никак, тем более что исправляться он явно даже не думает.
Остается печальный svn, и вроде бы совсем не печальный bzr, к которому можно прикрутить чужой docdiff, хотя это выглядит несколько нечестно и тиражировать решение со словами "просто скачай и запусти этот экзешник" уже не получится.
|
|
|
| Еще одно некорректное исправление tzdata для python на примере 2011k |
[Oct. 30th, 2011|04:10 pm]
Denis
|
Если верить исходникам python, а именно timemodule.c, то timezone и altzone определяется по janzone и julyzone , т.е. как не издевайся над tzdata, в этом году python нормально зоны не определит, единственный вариант это указать что в январе 2011 года зона была не UTC+3, а UTC+4, сделать это можно например путем отмены перевода на зимнее время уже в 2010.
Windows кажется поступил примерно так, потому что:
denis@server~$ python -c "from time import *;t=mktime((2010,05,01,0,0,0,0,0,0));l=localtime(t);print l.tm_isdst"
1
denis@server~$
и
C:\tmp>python -c "from time import *;t=mktime((2010,05,01,0,0,0,0,0,0));l=localtime(t);print l.tm_isdst"
0 C:\tmp>
Оригинальная tzdata: root@debian6:/tmp/tzdata# zic europe
root@debian6:/tmp/tzdata# dpkg-reconfigure tzdata
Current default time zone: 'Europe/Moscow'
Local time is now: Sun Oct 30 15:43:44 MSK 2011.
Universal Time is now: Sun Oct 30 11:43:44 UTC 2011.
root@debian6:/tmp/tzdata# python -c "import time;print time.timezone;print time.altzone;print time.daylight"
-10800
-14400
1
root@debian6:/tmp/tzdata# zdump /etc/localtime -v|tail
/etc/localtime Sat Oct 24 22:59:59 2009 UTC = Sun Oct 25 02:59:59 2009 MSD isdst=1 gmtoff=14400
/etc/localtime Sat Oct 24 23:00:00 2009 UTC = Sun Oct 25 02:00:00 2009 MSK isdst=0 gmtoff=10800
/etc/localtime Sat Mar 27 22:59:59 2010 UTC = Sun Mar 28 01:59:59 2010 MSK isdst=0 gmtoff=10800
/etc/localtime Sat Mar 27 23:00:00 2010 UTC = Sun Mar 28 03:00:00 2010 MSD isdst=1 gmtoff=14400
/etc/localtime Sat Oct 30 22:59:59 2010 UTC = Sun Oct 31 02:59:59 2010 MSD isdst=1 gmtoff=14400
/etc/localtime Sat Oct 30 23:00:00 2010 UTC = Sun Oct 31 02:00:00 2010 MSK isdst=0 gmtoff=10800
/etc/localtime Sat Mar 26 22:59:59 2011 UTC = Sun Mar 27 01:59:59 2011 MSK isdst=0 gmtoff=10800
/etc/localtime Sat Mar 26 23:00:00 2011 UTC = Sun Mar 27 03:00:00 2011 MSK isdst=0 gmtoff=14400
/etc/localtime Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 07:14:07 2038 MSK isdst=0 gmtoff=14400
/etc/localtime Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 07:14:07 2038 MSK isdst=0 gmtoff=14400
root@debian6:/tmp/tzdata#
Отмена перевода в 2010:
root@debian6:/tmp/tzdata# zic europe.new
root@debian6:/tmp/tzdata# dpkg-reconfigure tzdata
Current default time zone: 'Europe/Moscow'
Local time is now: Sun Oct 30 15:44:22 MSK 2011.
Universal Time is now: Sun Oct 30 11:44:22 UTC 2011.
root@debian6:/tmp/tzdata# python -c "import time;print time.timezone;print time.altzone;print time.daylight"
-14400
-14400
0
root@debian6:/tmp/tzdata# zdump /etc/localtime -v|tail
/etc/localtime Sat Oct 25 22:59:59 2008 UTC = Sun Oct 26 02:59:59 2008 MSD isdst=1 gmtoff=14400
/etc/localtime Sat Oct 25 23:00:00 2008 UTC = Sun Oct 26 02:00:00 2008 MSK isdst=0 gmtoff=10800
/etc/localtime Sat Mar 28 22:59:59 2009 UTC = Sun Mar 29 01:59:59 2009 MSK isdst=0 gmtoff=10800
/etc/localtime Sat Mar 28 23:00:00 2009 UTC = Sun Mar 29 03:00:00 2009 MSD isdst=1 gmtoff=14400
/etc/localtime Sat Oct 24 22:59:59 2009 UTC = Sun Oct 25 02:59:59 2009 MSD isdst=1 gmtoff=14400
/etc/localtime Sat Oct 24 23:00:00 2009 UTC = Sun Oct 25 02:00:00 2009 MSK isdst=0 gmtoff=10800
/etc/localtime Fri Mar 26 22:59:59 2010 UTC = Sat Mar 27 01:59:59 2010 MSK isdst=0 gmtoff=10800
/etc/localtime Fri Mar 26 23:00:00 2010 UTC = Sat Mar 27 03:00:00 2010 MSK isdst=0 gmtoff=14400
/etc/localtime Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 07:14:07 2038 MSK isdst=0 gmtoff=14400
/etc/localtime Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 07:14:07 2038 MSK isdst=0 gmtoff=14400
root@debian6:/tmp/tzdata#
diff:
root@debian6:/tmp/tzdata# diff -u europe europe.new
diff:
root@debian6:/tmp/tzdata# diff -u europe europe.new
--- europe 2011-09-21 01:44:59.000000000 +0400
+++ europe.new 2011-10-30 15:42:46.000000000 +0400
@@ -2080,7 +2080,7 @@
2:00 - EET 1930 Jun 21
3:00 Russia MSK/MSD 1991 Mar 31 2:00s
2:00 Russia EE%sT 1992 Jan 19 2:00s
- 3:00 Russia MSK/MSD 2011 Mar 27 2:00s
+ 3:00 Russia MSK/MSD 2010 Mar 27 2:00s
4:00 - MSK
#
# Astrakhanskaya oblast', Kirovskaya oblast', Saratovskaya oblast',
root@debian6:/tmp/tzdata#
Ну и в следующем году уже можно будет перейти на обычный tzdata.
|
|
|
| (no subject) |
[Oct. 23rd, 2011|11:26 am]
Denis
|
Гугл стал совсем плохой, он конечно и раньше считал себя умнее и выкидывал или изменял слова по собственному желанию, но это легко корректировалось написанием + там где нужна точность. А теперь при указании + выводится сообщение:
Оператор "+" был заменен.
Чтобы найти определенное словосочетание, выделите его двойными кавычками.
Кавычки вроде бы действительно работают, но они на счастье совсем не похожи, для начала в разных раскладках они расположены на разных местах, а уж то что их требуются две, это вообще скорее безобразие, ну и кроме этого кавычки раньше были самостоятельным инструментом, который можно было сочетать с плюсом.
В хелпе гугла кстати плюс все еще остался, но при поиске примера он его убирает.
|
|
|
| Проверка скорости записи на диск для linux |
[Oct. 13th, 2011|11:03 pm]
Denis
|
В windows разочароваться в реальной скорости диска (без кэша ОС) помогает DiskTT, в linux с этим почему-то все оказалось сложнее. Просто dd if=/dev/zero of=file активно работает с кэшом ОС и выдает страшное количество мегабайт, всякие разновидности sync’ов тоже не приносят особой ясности на тему как же это все работает, когда у операционной системы совсем кончится память для кэширования. Но вот тут нашлось описание, как же узнать реальную скорость работы.
Краткий и почти не совпадающий перевод:
1. dd bs=1M count=128 if=/dev/zero of=test
Выполнение этой команды запишет 128МБ в буфер (кэш записи), команда покажет достаточно высокую скорость записи, которая будет достаточно далека от реальности.
2. dd bs=1M count=128 if=/dev/zero of=test; sync
Идентично предыдущему варианту (хотя на самом деле если сделать time sh -c "dd bs=1M count=128 if=/dev/zero of=test && sync" то результат будет более осмысленным)
3. dd bs=1M count=128 if=/dev/zero of=test conv=fdatasync
Это уже настоящий sync в правильном месте, dd покажет правильные мегабайты в секунду, но кэш во время записи использоваться все равно будет.
4. dd bs=1M count=128 if=/dev/zero of=test oflag=dsync
Результат похож на DiskTT с запрещенным кэшом windows, синхронизация с диском будет выполняться после записи каждого блока данных, т.е. в данном случае 128 раз и можно увидеть достаточно реальную скорость работы дисковой подсистемы (конечно через файловую систему, но тем не менее) . Именно в этом режиме 5400 SATA в разы быстрее 10K SAS с отключенным кэшом рейда.
А вот дальше там зачем-то предлагается использовать conv=fdatasync как наиболее правильный, что странно, по хорошему это все проверять нужно на относительно свободной системе, в то время как совсем неудовлетворительные результаты можно получить когда например вся память будет совсем занята и преимущества кэша использовать уже не получится, так что мне кажется что самый честный вариант это 4, а 3 можно использовать для определения как оно все будет работать, когда сервер не будет полностью загружен. |
|
|
| И еще раз про python, tzdata и linux |
[Oct. 10th, 2011|08:25 pm]
Denis
|
GMT-4 выглядит все же несколько дико и в классическом понимании относится к чему-то весьма отдаленному от MSK.
Workaround:
root@server /tmp# echo "Zone MSK +4:00 - MSK" > MSK
root@server /tmp# zic -d /usr/share/zoneinfo/Europe/ MSK
root@server /tmp# mv /etc/localtime /etc/localtime-
root@server /tmp# ln -s /usr/share/zoneinfo/Europe/MSK /etc/localtime
root@server /tmp# python
Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.daylight
0
>>> time.timezone
-14400
>>> time.altzone
-14400
>>> time.tzname
('MSK', 'MSK')
>>>
root@server /tmp#
Практически счастье, но нет истории перевода часов. Пытался допилить tzdata до вменяемого состояния чтобы эту историю сохранить, но ничего так и не вышло, упорно пишет -10800 |
|
|
| python, linux и tzdata |
[Oct. 9th, 2011|07:19 pm]
Denis
|
Удивительно, но после апдейта tzdata в debian python стал вести себя довольно неадекватно.
Вот например windows:
>>> import time
>>> s=time.mktime((2011,10,9,0,0,0,0,0,0))
>>> l=time.localtime(s)
>>> l.tm_isdst
0
>>> time.daylight
0
>>> time.timezone
-14400
>>> time.altzone
-18000
>>>
Debian с новой tzdata
>>> import time
>>> s=time.mktime((2011,10,9,0,0,0,0,0,0))
>>> l=time.localtime(s)
>>> l.tm_isdst
0
>>> time.daylight
1
>>> time.timezone
-10800
>>> time.altzone
-14400
>>>
Debian со старой tzdata
>>> import time
>>> s=time.mktime((2011,10,9,0,0,0,0,0,0))
>>> l=time.localtime(s)
>>> l.tm_isdst
1
>>> time.daylight
1
>>> time.timezone
-10800
>>> time.altzone
-14400
>>>
От такого разнообразия у софта несколько сносит крышу, дополнительного счастья видимо добавляет time.tzname ('MSK', 'MSK') вместо ('MSK', 'MSD'), в результате вполне корректное московское время линукса в питоне вдруг становится не UTC+4, а UTC+3.
Перенастройка в GMT-4 (!минус 4) успешно помогает, время становится UTC+4, daylight=0 и все похоже на правду, только у времени теперь нет суффикса MSK/MSD.
|
|
|
| Про скорость дисков |
[Oct. 1st, 2011|03:58 pm]
Denis
|
Достаточно любопытное и простое описание мониторинга ввода/вывода в linux, в контексте последних событий прочитал с интересом, и про диски тоже хорошо написано.
( Read more...Collapse ) |
|
|
| navigation |
| [ |
viewing |
| |
most recent entries |
] |
| [ |
go |
| |
earlier |
] |
| |
|
|
