Soci (Soczó Zsolt) szakmai blogja

Az utóbbi napokban játszok a tőzsdén, mert az érdekes. Már Bálint is kérdezte, hogy apa, ma is játszunk tőzsdéset? :)

A CIB-nél rendeltem meg az E-brokit, eddig általában jól ment, de ma annyira bezsongtak az emberek az ojtépére, hogy beszart a webszerverük. Kereskedj, wazze. :(

Service Temporarily Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Oracle-Application-Server-10g/10.1.2.2.0 Oracle-HTTP-Server Server at www.ebroker.hu Port 7782

Más kérdés, hogy a terhelés miatt miért jön ilyen hibaüzenet is?

Not Found
The requested URL /pls/ebrb/ebr_nyer_veszt_html_p.startup was not found on this server.

Ha valaki tűzközelben van a CIB-nél, és nem árul el atomtitkot, akkor érdekelne, hogy mekkora farmot hoztak létre az ebroker céljára, és mennyire skálázható az architektúra, mondjuk 1 órán belül fel lehet-e bővíteni a duplájára. :)

Amúgy az erstés rendszer is beszart előző héten, de lehet, hogy most is.

A cégnek egy hookolós kódot próbálok 64 bitre kibővíteni, de állandóan befagyott tőle a gép, csak a restart segített rajta. Meglehetősen frusztráló. Nagyon. :)
Nyilvánvalóan deadlock gond volt, de mégis, ki-kivel és min akadt össze?
Mivel hookolós a kód, még debugolni se lehet, és még az OutputDebugString is okozhat deadlockot, így még azzal se lehet tracelni. Eléggé fekete doboz így a rendszer.
A megoldást az adta, hogy a Fast User Switching segítségével beléptem egy másik felhasználó nevében, és lefutattam a LockWatchert.
Mivel a programban a várakozások WaitForMultipleObjects-en történtek nem írta ki, hogy deadlock van (írja is a cikk, hogy így viselkedik), de szemre szépen látszik így is az összeakadás.
Jó eszköz, szeretjük. Kár, hogy csak Vistán van hozzá API támogatás. Ebből is látszik egyébként, hogy a Vista nem csak az új shellről szól, mint sokan hiszik, hanem sok belső újítás is van benne.

Valahol láttam ezt a könyvet, mosolyogtam egyet rajta, némileg még igazat is adtam neki, de úgy vagyok vele mint Michael Moore filmjeivel, hogy ugyan van alapjuk, de azért sarkított véleményeket kapunk.
Annak ellenére, hogy már egyszer megjártuk, Bálinttal. Most szegény Benedek szívta meg, az egyik pici.
Bő hete mindkét picur elkapta a bátyjuk, Bálint által hazahozott óvodai vírust. Mindketten betaknyosodtak, Pannikának a fülére is ráment valamennyire, de ő szokás szerint gyorsan leküzdötte a vírust.
Benedek esetén már tapasztalatból tudjuk, hogy ő lassabban bír a takonykórral, előzőleg hetekig hörghurutja lett tőle. Most már felkészültebbek voltunk, vettünk váladékszívót, így sós vízzel minden nap minden gyerek orrát átmostuk.
Benedeket elvittem Törökbálintra a pulmonológiára, mert az előző alkalommal gyógyulás után vittem oda, és azt mondták, majd betegen megnéznék még egyszer. Legyen. Megnézték, igen, hörghurut, nem tüdőgyuszi (a háziorvos hallgatózva azt diagnosztizálta). Már napok óta szedett antibiotikumot, így jó úton haladtunk a gyógyulás felé.
Ám a tüdőgyógyász, nem tudom miért, de meg akarta nézni Bendek fülét is (egy tüdőgyógyász, minek?). Ebből lett a baj. Mivel a fülzsírtól nem látta a dobhártyát, elővett valami dróthurkos szarságot, amivel elkezdte piszkálni a füléből a fülzsírt. Persze Benedek ordított és ugrált nagyon, ennek ellenére csinálta. Megnézte, rendben van a füle. Kijövet már láttam, hogy vérzik a füle, de mivel eléggé rossz volt a megvilágítás nem voltam benne biztos, hogy vér, nyugtattam magam, hogy fülzsír.
Kb. 2 nap múlva egyre rosszabb lett Benedek állapota, sokat sírt, fogta a bal fülét, és belázasodott. Annak ellenére, hogy még mindig szedte az antibacit. Mivel éjszaka már alig aludt vasárnap elvittem gégészeti ügyeletre, ahol megállapították, hogy megsérült a hallójárata, ami miatt hallójárat gyulladása lett. Feleségem szerint ez nagyon fájdalmas, neki volt már ilyen.
Most még mindig alig tud szegény aludni, ha hozzáérünk a füle környékéhez azonnal ordít, annyira fáj neki. Már 4. napja.
Köszönjük a piszkálódást, Ujszászi Éva doktor néni. :(

Itt.

A screencast nem olyan pörgős és humoros mint az elő előadás volt, de nem szeretek a monitornak bohóckodni. 500 embernek már lehet. Előadás közben meglepően más helyen vagyok a tudatállapotok szivárványán, pedig nem is kokszolok. :)
Persze tartalmilag minden benne van, ami élőben ment. Jó tanulást hozzá!

Működik jól.

Nem gondoltam, hogy engem valaha érdekelni fog a dolog, de ez a pénzügyi trutymó ami most van, egybekötve azzal, hogy vannak befektetéseim érdeklődést váltott ki belőlem, hogy is működik ez a részvényesdi, tőzsdézős izé. Egyrészt, hogy mit várhatok a befektetett pénztől, másrészt, hogy tényleg jó beszállási lehetőségek vannak-e most, ha igen, kihasználni őket. Büfé úr már vásárol, de neki kicsit több befektetnivalója van, mint nekem. :) Sokan nekiestek az OTP-nek, rengetegen buktak is vele, vagy beragadt a pénzük. Mások elég jól kerestek vele. Mi különbözteti meg a két csapatot egymástól? Erről szól a könyv. :)
Ez az első ilyen témájú könyvem, és nagyon érdekes olvasmány. Akit érdekel, mi történik a háttérben az emberek fejében, annak ajánlom a könyvet, ha van 5 perc szabadidőm, most ez olvasom. Aki be van szarva ebben a helyzetben (ki nem), annak különösen ajánlom a művet.

Ha valaki tudna nekem ajánlani olyan alapvető könyvet, ami arról szól, hogy technikailag hogyan működik a tőzsde, milyen szabályok szerint, kérem jelezze, vevő lennék rá. Pl. hogyan állítják be a napi kezdő árfolyamokat, pontosan hogyan mozognak az árfolyamok az eladások és vételek hatására, stb.

Előző héten (amerikai) angol tanfolyamon választásosat játszottunk. A tanár amerikai állampolgár, lemásolta a szavazólapját, arról beszélgettünk és a végén szavaztunk.
Az eredmény (számomra, aki nem nagyon követi a politikát) több, mint meglepő volt: 14:4 arányban Obama győzött.
Ez nekem azt mutatja, hogy lehet, hogy nálunk mégse a szín, hanem a viselkedés alapján vannak ellenérzések, feszültségek a társadalomban, bármennyire is az ellenkezőjét akarják bizonyítani nácizással?
Persze, az ott van, ez meg itt, nem feltétlen jó a párhuzam, de elgondolkodtató volt számomra.

Örömmel és nagy reményekkel közzéteszem, hogy 2009. január 1.-től független szaktanácsadóként folytatom a szakmai pályafutásom. Ennek megfelelően év végére átalakítom a website-om főlapját is, a megfelelő üzleti, kontakt, stb. információkkal kiegészítve.
A blogom változatlanul fog üzemelni, sőt, várhatóan több időm lesz rá, és jóval több témával is fogok foglalkozni (WCF, WWF, Windows Internals, DP újult erővel, stb.).

Ha .NET-alapú fejlesztéssel, tervezéssel vagy SQL Serverrel kapcsolatban tudok valakinek segíteni, januártól szabad vagyok. Az utóbbi két évben jó pár felkérést utasítottam vissza, jövőre erre már nem lesz szükség.

Részletek később, most igen sok intéznivalóm van…

Bosszantó módon a 2008-as SQL Management Studioban nem működnek a megszokott shortcutok, mint a CTRL-N új fájlokhoz, vagy az F8 az object explorerhez. Állítólag ez nem szándékos, hanem bug.
Megolás: Tools, Options, Environment, Keyboard, Keyboard scheme átállítani 2000-resre, majd vissza. Nálam bejött.

Előző héten és ma is vizsgáztam egy-egy SQL 2008 vizsgán, hamarosan leírom az élményeimet. Addig is egy kis csemege, ami benne volt.
Mit jelent, ha a várakozások (sys.dm_os_wait_stats) között jelentős szereplő a SOS_SCHEDULER_YIELD?
Az SOS az SQL OS rövidítése, kvázi OS az OS-ben, sok írás van róla az interneten.

Konkrétan, ha a SOS_SCHEDULER_YIELD értéke jelentős, akkor túl van terhelve a proci.

A hack szót nem szeretem, mert valami kókányolás, tákolás jut róla az eszembe, de ez a site megér egy misét. Sok-sok hasznos tipp van rajta, sql programolóknak.
Pl. nézzük ezt. Nagyon ravasz eset, ami bárki belefuthat, ha egyszer csak megjelenik NULL valamelyik oszlopban, és beborul a lekérdezés tőle.
Sajnos ennél például nem írják le, milyen logika miatt nem az az eredmény jön vissza, amit elvárunk, de itt pl. van hozzá némi ideológia.
Ha én kezdő vagy középhaladó sql programoló lennék, minden nap elolvasnék is kipróbálnék egy cikket, sokat lehet belőlük tanulni. (Így is el fogom, csak nem napi egyet, hanem egyszerre sokat, valamelyik éjszaka. :)

Update: érdemes feliratkozni a feedjére.
Sajnos nem találtam feedet, ami csak erről szólna, ebben más is benne van (mondjuk azok se rosszak, de szeretek célirányosan infókat olvasni.) Ha valaki találna, kérem jelezze.

Ezen összehasonlítás alapján hosszú távon az Atom fog győzni, mivel pont az RSS hiányosságait igyekszik kiküszöbölni.

http://learn.iis.net/page.aspx/208/fastcgi-with-php/

Windows 2008 kell hozzá, mert ugye ez IIS7 fícsör.

Sokan nem identity-s int-et hanem uniqueidentifiert használnak pk-ként olyan táblákban, amelyet több helyen módosítanak, pl. replikációs felállásban. Nagyon helyesen.
A gond csak az, hogy a NEWID()-val generált értékek tényleg nagyon véletlenszerű értékek (és a közhiedelemmel ellentétben nincs benne a MAC address, mint régen). Ha a generált értéket egy clustered indexes (leggyakrabban primary key-es) oszlopban használjuk, akkor ez egymás után következő beszúrások véletlenszerű helyre kerülnek az adatbázis fájlban (ez így pongyola, de nem akarom túlrészletezni), és széttöredezik a tábla ezer darabra, ráadásul a lapok nem lesznek jól kitöltve, és mégis sok page split lesz. Szóval gáz lesz az insert teljesítménye. Ezen segíthet a NEWSEQUENTIALID függvény, ennek teljesítményét és fragmentálási hatását vizsgálja ez a cikk.
Akinek ilyen jellegű az adatbázisa feltétlen olvassa el a cikket. Százszoros fragmentáció esetén csak megéri elgondolkodni, nem?

Emailben kérdezték tőlem gáz-e, hogy a profilerben a logut eseményeknél jó nagy duration és egyéb értékek vannak.
Röviden: nem.

Hosszabban: a logout események adatai nem túl érdekesek, azok az adott connection által végzett összes munka és várakozás idejét tartalmazzák. Ha lezárod rendesen a kapcsolatokat kliens oldalon, akkor azt várod, hogy a login-logut események rövid időn belül követi egymást, de nem ez történik a
connection pooling miatt. A pooling alapban be van kapcsolva az összes adatelérő komponensben, ezért egy kapcsolat percekig fennáll a kliens és a szerver között, amin sok általad megnyitott kapcsolat pöfögi át a parancsait. Ezért a logoutnál látott érték sok lekérdezés és a közöttük eltelt várakozási idő együttes eredménye.

A pooling=false connection string paraméterrel teszt célból kikapcsolhatod a poolingot, hogy lásd a különbséget. De ezt élőben ne tedd, mert nagyon lelassul tőle az appod, nem véletlenül van bekapcsolva.

Szóval általában nem kell foglalkozni a logout idejével.

Tök jó oktatóanyagok jellennek meg pár naponta a devportálon a témában.

Először azt hittem WPF tanfolyam megy, de ez csak jó, ha egy csapásra két dolgot tanulhat az ember.

A briteknek megvan a magukhoz való esze – velünk szemben:

“The Department for Work and Pensions (DWP) takes benefit theft very seriously. Although the vast majority of people who claim benefits are honest, those who steal benefits are picking the pockets of law-abiding taxpayers. In 2007-08 benefit thieves stole an estimated £800 million from public funds, that’s why we are determined to catch them.

Benefit theft includes deliberately not telling us:

* you are now living with a partner
* about any savings or not telling us the right amount
* children have left home
* you have started work, or about any earnings
* you have inherited money
* you are going abroad, living abroad, or have changed address.

There are no exceptions. People who knowingly withhold information or deliberately fail to report a change in their circumstances are benefit thieves. It is not ‘playing the game’ – it is breaking the law!”

Vö. a mi kormányunk hozzáállásával:
“a kormány a szociális biztonságot nem fogja a gazdasági növekedés oltárán feláldozni”.
Ez itt a probléma, kérem, többek között.

SQL 2008-ban jelent meg a FILESTREAM, amivel tipikus használat esetén 1 megánál nagyobb fájlokat nem az adatbázisban, hanem fájlrendszerben tároltatjuk le a szerverrel, így hatékonyabb lesz a tárolás, és win32-n keresztül is el lehet érni az adatokat, hatékonyabban, mint TDS-en keresztül. De erről már írtam sokat.
Amire fel akarom hívni a figyelmed, az ez a cikk, amiben tippeket adnak, amitől gyorsabb lesz a filestream.

Kiemelném a következőt:

“Turn off 8.3 name generation on the NTFS volume. This is an order-N algorithm that has to check that the new name generated doesn’t collide with any existing names in the directory. This slows insert and update performance down *a lot*. Do this using the command line fsutil utility.”

Ez érdekes, nem? Azaz, ha egy könyvtárban nagyon sok fájl van, a fájlok létrehozása és átnevezése nagyon lelassul a 8.3-as nevek miatt. A fene ezt a szar DOS-t. :)
Megjegyeztük.

A dátum ne tévesszen meg senkit, az RTM-ben még csak az RC0-val egyező doksi van, ezzel a frissítéssel lesz teljes az RTM doksi.
Letöltés.
Windows update-tel majd csak október közepén jön le, elvégre ez nem kritikus dolog.

Október végén lesz újabb frissítés is hozzá, addigra visszarakják a most kidobott What’s new szekciót is.

Annak idején az SQL 2000 kapcsán úgy tanultam, hogy az sql server okosan bánik a memóriával, és ha a szabad RAM mérete 5 MByte alá esik, akkor a Lazy Writer elkezdi kiírni a módosított lapokat a diszkre. Teszi ezt azért, hogy ne kezdjen el lapozni az oprendszer.
2005-ben azonban elkezdtem azt tapasztalni, hogy az sql server túlzabálta magát, és az oprendszer mégis csak keményen lapozott alatta, és úgy tűnt, hogy nem más processzek miatt, hanem az SQL Server miatt.
Az MVP newsgroupon olvasom, hogy másoknak is van ilyen problémája. 8 G RAM volt a gépben, az SQL Server 6 G-ra volt bekorlátozva. Más folyamatok, mint Database Mail, stb. miatt azonban még így is nagy lapozások történtek, erről az SQL Server ír is az error logjában (A significant part of sql server process memory has been paged out. This may result in a performance degradation.).
A kollégának 4 Gigára vissza kellett húzni a max memory beállítást, hogy megnyugodjon a szerver. Ez másnak is bevált. Jó erről tudni.

Van, akinek az OS File Cache viszi el a ramot. Nekem is gyanús volt már egyszer, ezek szerint nem véletlenül. Van egy beállítás a System applet mögött (Performance Options, Advanced, Memory, Adjust for best performace of Programs vagy System Cache), hogy file server vagy application server üzemmódban működjön a szerverünk. Ez pont a File Cache méretét szabályozza, tehát ha ez rosszul van beállítva egy SQL Serveren, akkor ez már gyanús lehet.

Nem csak a File Cache szoríthatja ki az SQL Servert a memóriából, de ha az, arra az alábbi cikk megoldást adhat.

Részletes elemzés és lépésenkénti hibakeresés a problémáról itt található.