Soci (Soczó Zsolt) szakmai blogja

2017.05.12.

Google Mock Test Adapter for VS 2017

Filed under: Szakmai élet — Soczó Zsolt @ 07:45

Az MS mögé állt, eddig külsősök írták. Végre kényelmesedik a C++ tesztelési irány is. Hát még, ha NCrunch is menne…

2017.01.17.

Nagy táblák join-olása eredmények

Filed under: Adatbázisok,SQL Server,SQL Server 2016,Szakmai élet — Soczó Zsolt @ 19:26

Korábbi bejegyzésemben írtam, hogy demó környezetben a columnstore indexek nagyon jelentős gyorsulást okoznak.

Élő adatbázisban azt tapasztaltuk, hogy integer kulcsokon végzett join-okon 5-10-szeres gyorsulást okozott a normál indexekhez képest.

Azonban GUID-os oszlopokkal nem okozott értékelhető gyorsulást, annak ellenére, hogy batch módúak voltak a műveletek. Erre úgy látszik nem gyúrtak még rá, vagy a guid randomsága miatt nem tud érdelmes teljesítményt elérni.

2016.11.22.

Nagy táblák joinolása

Egyik folyó munkámban több tízmilló soros táblákon végzett joinokat kellett optimalizálni. Általában ez nem kihívás, mert szinte mindig vannak szűrési feltételek, amelyeket kellő közelségbe víve a táblákhoz és rendes indexekat alápakolva már csak pár ezer joint kell végrehajtani, ami gyors lesz.
De most tényleg össze kellett joinolni sok millió sort, szűrés nélkül.
Mit lehet ezzel kezdeni? Sajnos itt már eléggé behatárolt területen mozgunk. A normál indexelős megoldások nem segítenek, mivel minden táblát teljes egészében be kell járni (nincs where).
Ráadásul ha *-os a select, akkor a cover NC index se játszik, hogy legalább az IO csökkenne.
Merge joinra lehet játszani clu indexekkel, de azért ez korlátos terület sok tábla esetén, illetve párhuzamos tervek esetén magától nem fog merge joint használni (itt írnak egy trace flagről, amivel mégis rá lehet venni).
Mit lehet tenni. Egyik lehetőség előre elkészíteni a join indexelt view-ban. Erre ügyesen ráharap az optimizer, ha van olyan join amit aztán többször futtatunk, akkor megéri ez a denormalizálás.
Ha viszont van újabb szerverünk (2016), akkor van sokkal durvább lehetőség: Columnstore index.
Az a baj ugye a nagy joinnal, hogy akárhogy is trükközünk, ez nagy meló a prociknak és az IO alrendszernek (vinkóknak). Az indexed view ezt úgy oldja meg, hogy egyszer kell megcsinálni, aztán sokszor élvezni az előre összepakolt adatokat.
A columnstore viszont (dióhéjban) azért piszok gyors mert:
1. 5-10-szeresen tömörítve tárolja az adatokat, kevesebb IO, illetve a memóriában a buffer cache-t is jobban ki tudja használni (mintha több RAM-unk lenne)
2. Képes az adatok csak egy részét felolvasni, ha csak kevés oszlop kell (select *-on ez nem segít persze)
3. Képes batch módban belülről párhuzamosan végrehajtani a műveletek egy részét (ez nagyon durván megdobja)
4. Képes a sorok egy részét felolvasni where feltétel alapján, mivel minden 1m sorhoz (szegmens) nyilván tarja az adott oszlop min és max értékét
5. Le tud nyomni operátorokat (pl. sum) a storage engine-be, így nem kell adatokat passzolgatni a rétegek között.

No, lássuk a medvét. Létrehoztam két másolatot egy 100 millió soros táblából. A tesztgép egy két éves laptop 2 core-ral és 8G RAM-mal, SSD-vel. Nem egy szerver.
A két táblát a kulcsai mentés join-olom, így mind a 100 millió sort végig kell néznie, és ennyi találat is lesz.

Először sima Clu index:
create clustered index IX_Clu1 on B1(Id)
create clustered index IX_Clu2 on B2(Id)

select count(*) from B1 join B2 on B1.Id = B2.Id

SQL Server parse and compile time:
CPU time = 15 ms, elapsed time = 18 ms.

(1 row(s) affected)
Table ‘B1’. Scan count 5, logical reads 1141262, physical reads 6,
read-ahead reads 1138814, lob logical reads 0, lob physical reads 0,
lob read-ahead reads 0.
Table ‘B2’. Scan count 5, logical reads 1140956, physical reads 4,
read-ahead reads 1138821, lob logical reads 0, lob physical reads 0,
lob read-ahead reads 0.
Table ‘Workfile’. Scan count 896, logical reads 480256, physical reads
2688, read-ahead reads 477568, lob logical reads 0, lob physical reads
0, lob read-ahead reads 0.
Table ‘Worktable’. Scan count 0, logical reads 0, physical reads 0,
read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob
read-ahead reads 0.

SQL Server Execution Times:
CPU time = 477262 ms, elapsed time = 377318 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 1 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

377 másodperc.

Jöhet a columnstore index:
create clustered columnstore index IX_CStore1 on B1
create clustered columnstore index IX_CStore2 on B2

select count(*) from B1 join B2 on B1.Id = B2.Id

SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 6 ms.

(1 row(s) affected)
Table ‘B2’. Scan count 4, logical reads 0, physical reads 0,
read-ahead reads 0, lob logical reads 105018, lob physical reads 0,
lob read-ahead reads 0.
Table ‘B2’. Segment reads 103, segment skipped 0.
Table ‘B1’. Scan count 4, logical reads 0, physical reads 0,
read-ahead reads 0, lob logical reads 104998, lob physical reads 0,
lob read-ahead reads 0.
Table ‘B1’. Segment reads 102, segment skipped 0.
Table ‘Worktable’. Scan count 0, logical reads 0, physical reads 0,
read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob
read-ahead reads 0.

SQL Server Execution Times:
CPU time = 79920 ms, elapsed time = 27834 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

377 sec vs. 28 sec. Azért ez masszív különbség. :)

Érdekességképpen megnéztem NC Columnstore index-szel is, úgy 60 sec jön ki. Ez se rossz.

A jövő héten lehet ki tudjuk próbálni egy nagyobb géppel is, kíváncsi vagyok, ott mit tudunk vele kihozni.

Ha esetleg valakinek vannak már gyakorlati sikerei, érdekelnek a számok.

2016.11.04.

Mit is jelent pontosan, hogy Accent Insensitive?

Filed under: Adatbázisok,SQL Server,Szakmai élet — Soczó Zsolt @ 12:18

Bólyai magyar verseny kapcsán gondolkodtam a magyar nyelv rendezési szabályain.

string[] words = new string[] { "írógép", "írat", "irkál", "irodalom", "író", "írás" };
Array.Sort(words, StringComparer.Create(new System.Globalization.CultureInfo("hu-hu"), false));
foreach (var w in words)
{
    Console.WriteLine(w);
}

Kimenet:

írás
írat
irkál
író
irodalom
írógép

Ezek szerint az alap magyar kultúra szerint a C# (valójában a Windows) accent insensitive módon rendez. A gyerekek is azt mondták, így tanulják az iskolában. Az én fejemben ez nem így volt. Vagy bugos a fejem, vagy mi még nem így tanultuk, nem tudom.

Nézzük SQL Serverben!

CREATE TABLE [dbo].[A](
	[Nev] [nvarchar](50) NOT NULL
) ON [PRIMARY]

select * from A
order by Nev collate hungarian_CS_AI

Azaz Accent Insensitive a rendezés, így joggal azonos a C#-pos kimenettel:

írás
írat
irkál
író
irodalom
írógép

Ami viszont bizarr:

select * from A
order by Nev collate hungarian_CS_AS

Kimenet:

írás
írat
irkál
író
irodalom
írógép

Ugyanaz! Magyar nyelv esetén nem számít az ékezet érzékenység, akkor se vesszük figyelembe az ékezeteket, ha kifejezetten kérjük. Ez nekem furcsa, de nem én írom a magyar nyelvi szabályokat.

Van egy másik collation is, annál meg mindig accent insensitive a rendezés, függetlenül a beállítástól:

select * from A
order by Nev collate Hungarian_Technical_CI_AS
select * from A
order by Nev collate Hungarian_Technical_CI_AI

Mindét esetben ez a kimenet:

irkál
irodalom
írat
írás
író
írógép

Tehát a magyar az egy olyan állatfajta, amiben nem az AI/AS szabályozza az Accent Sensitivity-t, hanem, hogy melyik collationt használjuk.

Ami viszont végképp fura, hogy a Latin1_General_100_CI_AS vs Latin1_General_100_CI_AI sem változtatja meg a sorrendet. Hogy van ez?

A mi aá, stb. variánsaink nem tartoznak az accentek közé?

Itt és itt érdekeseket írnak a témáról.

2016.08.19.

Windows Internals cikkeim

Filed under: Szakmai élet,Windows,Winternals — Soczó Zsolt @ 11:22

Annak idején írtam pár cikket a Windows belső működéséről, utóbbi időben többen kerestétek, mivel eltűntek az ms oldalairól.

Ezért most kiraktam ide őket, hogy bárki elérhesse.

2016.06.19.

SQL Server memória hiány miatti lassú lekérdezés

Érdekes hibába futottam bele mostanában. A lapotopomban csak 8G RAM van, így az azon futó SQL servernek nem sok marad, amikor a Chrome, a Visual Studio 2015 és más memóriazabáló alkalmazások elkezdenek terjeszkedni.
A probléma az volt, hogy egy olyan lekérdezés, amely Sortot tartalmazott a szokásos 2-3 mp helyett fél-egy percig futott. A végrehajtási tervben volt egy figyelmeztetés, hogy a sort operátor kénytelen kipakolni a rendezést a tempdb-be (spill). De ettől még nem kellett volna ilyen lassúnak lennie. Csak 3500 sorról volt szó, ez azért belefért volna memóriába.

A select * from sys.dm_exec_query_memory_grants lekérdezésből kiderült, hogy a lekérdezés sortjának kellett volna 10M memória, de nem tudott annyit kapni, ezért várakozott, és aztán 20 másodperc múlva egyszer csak timeout lett, és kényszeredetten csak nekifogott végrehajtani a sortot a tempdbben.

Azaz egy egy nem szokványos lassú lekérdezés volt, nem sok lapolvasással járt, mint a tipikus rosszul optimalizált lekérdezések, hanem a memory grantre várt.
A megoldás az lett, hogy beállítottam 1G min memory-t az SQL Servernek, így már kiszámíthatóan jól érzi magát.

Egy rendes szerveren valószínűleg ritkább az ilyen memória kényszer, de azért jó tudni róla.

2016.02.28.

Ha a Visual Studio (2015) üresjáratban megeszik 1-2 procit…

Filed under: Szakmai élet,Visual Studio — Soczó Zsolt @ 20:11

akkor kapcsold ki a Git Source Control típust, mint default providert. Piszok idegesítő volt ez a hiba.

2015.12.22.

Egy példa mitől fordul le állandóan egy .NET project

Filed under: .NET,Szakmai élet — Soczó Zsolt @ 19:02

Bosszantó, amikor semmit nem változtatsz, mégis újrafordul pár project egy nagyobb solutionben. Ha bekapcsolod a diagnostic build loglevelt, akkor egyből kiderül az ok. Pl. most nálam:

Project ‘Basics’ is not up to date. Project item ‘C:\ATS\Basics\x64\lz4X64.dll’ has ‘Copy to Output Directory’ attribute set to ‘Copy always’.

Update: egyéb okok: felesleges referenciák illetve Resource-ként megjelölt file, ami nem is resource, csak sima xml, ki kell másolni a kimenetbe.

.NET fejtörő

Filed under: .NET,Szakmai élet — Soczó Zsolt @ 15:29

Élő kódból. Az első megoldás jól működik, a második nem, mi lehet az oka? A hibajelenség, hogy az első beállítja a TickerId-t az objektumon belül, a második nem.

Parallel.For(0, tickOhlcs.Count, i => tickOhlcs[i].SetTickerId(key.TickerId));

Parallel.ForEach(tickOhlcs, tickOhlc => tickOhlc.SetTickerId(key.TickerId));

2015.11.16.

TDD következő alkalom early bird

Filed under: .NET,Felhívás,Szakmai élet,Test Driven Development,Testing — Soczó Zsolt @ 23:19

Jövő januárban újra lesz TDD tanfolyam, most ősszel már nem volt időm betervezni egyet.

Aki december 1-ig jelentkezik, azt most 150e-ért csatlakozhat.

2015.09.17.

SQL Server change tracking cikk

Filed under: Adatbázisok,SQL Server,SQL Server 2008,Szakmai élet — Soczó Zsolt @ 20:21

Annak idején írtam egy jó hosszú cikket a témában, hogyan lehet offline, disconnected appokat írni, amiben adatokat kell szinkronizálni. Valamiért már nem volt kinn a weben, ezért most kiraktam ide újra.

Olvassátok egészséggel.

2015.06.24.

2 karakter, és máris más az execution plan

Az eredeti lekérdezésben az ORDER BY így nézett ki: order by BDT.
Ez a számított oszlopra vonatkozott, azért a szervernek meg kellett oldania a rendezést egy külön lépésben. A b.BDT után viszont már tudja használni az alatta levő index rendezettségét, így nem kell rendeznie. 4x teljesítménynövekedést okozott ez a 2 karakter.

select
dateadd(second, @dtModifier, BDT) BDT,
cast(O as real) O, 
cast(H as real) H, 
cast(L as real) L,
cast(C as real) C,
V
from dbo.Bar b with (nolock)
where b.TickerID = @TickerID
and b.BDT >= @StartDate
and I = @I
order by b.BDT

2015.06.16.

Intra query deadlock

Ma láttam egy újfajta deadlockot, amiben az SQL Server által párhuzamosan végrehajtott lekérdezés szálai akadtak össze. Azaz ugyanaz a PID akadt össze magával.

Először arra gondoltam, lefogom 1 szálra a lekérdezést maxdoppal, de szerencsére nem volt jól optimalizálva, így jól fel lehetett gyorsítani. 240000 lapolvasásról 4-re. :) Így már magától soros lett a plan, volt deadlock, nincs deadlock.

Bob is írt már erről.

2015.05.22.

SQL ad-hoc gyöngyszem

Filed under: Adatbázisok,SQL Server,Szakmai élet — Soczó Zsolt @ 13:47

Itt egy csodaszép szerver, amin az AD-HOC beállítás 6G RAM-ot spórolna.

PlanCacheTeleSzemettel

Előzmény.

Exam 70-459: https://www.microsoft.com/learning/en-in/exam-70-459.aspx done

Na, ez is megvan. :)

Ez is upgrade, két vizsgát tartalmazott, és ebben már volt 2014-es tartalom. Két témakört érintettek, az egyik az In-Memory DB (mi más?), a másik a delayed durability. Ja, és a clustered columnstore index is előjött egy kérdésben.

Szokás szerint volt pár nem jól definiált kérdés, ezeknél már kommenteztem, mert utálom, hogy ennyire nem nézetik át a kérdéseket.

Az in-memory-snál elég sokat elidőztem, mivel belementek, hogy milyen izolációs szintek vannak benne, és melyik alkalmas az adott feladatra, amit a scenarióban leírtak. A scenariók itt is km hosszúak, kicsit be is tojtam az elején, hogy nem lesz elég időm. De kiderült, hogy sok nem scenarió alapú kérdés is volt, azokat gyorsan meg lehet válaszolni.

Csak az inmemory-s rész a maga kb. 5 kérdésével elvitt vagy 20 percet, de a többi már emészthetőbb volt.

Idén már csak két tervem van, az MVC vizsga és a BI-os SQL rész. Az MVC-t valszeg letolom jövő héten még, amíg tart a second shot, ki tudja, hátha egyszer megbukom, nyugalmat ad, hogy nem dobok ki 75EUR-t az ablakon.

2015.05.21.

Szeméttel teli plan cache

Filed under: Adatbázisok,SQL Server,Szakmai élet — Soczó Zsolt @ 19:17

Ha a plan cache tele van csak egyszer használt planekkel, akkor azok csak feleslegesen eszik a memóriát.
Az alábbi lekérdezés erre világít rá:

SELECT objtype AS [CacheType]
        , count_big(*) AS [Total Plans]
        , sum(cast(size_in_bytes as decimal(18,2)))/1024/1024 AS [Total MBs]
        , avg(cast(usecounts as bigint)) AS [Avg Use Count]
        , sum(cast((CASE WHEN usecounts = 1 THEN size_in_bytes ELSE 0 END) as decimal(18,2)))/1024/1024 AS [Total MBs – USE Count 1]
        , sum(CASE WHEN usecounts = 1 THEN 1 ELSE 0 END) AS [Total Plans – USE Count 1]
FROM sys.dm_exec_cached_plans
GROUP BY objtype
ORDER BY [Total MBs – USE Count 1] DESC

Megkérnélek benneteket, akik éles, nagy terheltségű SQL szervert üzemeltetnek, hogy futtassátok le a fenti parancsot, és küldjétek el az eredményt, kíváncsi vagyok, hol-milyen eredmények jönnek vissza.

2015.05.20.

SQL Server 2014 SP1 letölthető

Filed under: Adatbázisok,SQL Server,SQL Server 2014,Szakmai élet — Soczó Zsolt @ 19:39

Innen.

Itt a fixek listája. Átszaladva a listán a túlnyomó többsége fix, nem sok új dolog van benne. Érdekes, hogy az in memory db részhez nincs benne fix. Kevesen használják még…

2015.05.15.

SQL Server 2016 In-Memory OLTP

Filed under: Adatbázisok,SQL Server 2014,SQL Server 2016,Szakmai élet — Soczó Zsolt @ 18:19

Úgy tűnik 2016-ra felnő, 1.0-ssá az In-Memory OLTP az SQL Serverben. Gondolkodik valaki a bevezetésén (úgy értem 14-ben) ?

Exam 70-457 Transition Your MCTS on SQL Server 2008 to MCSA: SQL Server 2012 done :)

Ma volt egy szabad napom, gyorsan lenyomtam ezt is.

A vizsga a szokásos volt, 0,8-e normál, rendes kérdések, 20% nehezen megragadható marhaság. 50 kérdés volt, ezzel le van tudva a 70-461 és a 70-462. 700 ponttól lehet átmenni, nekem 833 volt a 461-es rész, 900 a 462-es. Látszik, hogy developer agyam van. :)

Ha jól emlékszem nem volt benne egyetlen 2014-es kérdés sem, ez számomra szomorú. Valójában én a 2014 vizsgákat akartam letenni, de nincsenek most ilyenek. Gondolom majd a 2016-osnál lesznek új vizsgák, nem akarják lejáratni két évente a certeket.

Ami érdekes volt, eléggé rámentek a Windowing Functionökre, erre érdemes mindenkinek gyúrni (egyébként is hasznosak). De csak a 2005-ös szinten kérdezték, nem mentek bele a 2012-es újdonságokba (framing), pedig itt vannak az igazi csemegék.

A következő lukas napon jön a 459, abban már tényleg várhatóak 2014-es kérdések, majd megírom, mire kíváncsiak.

2015.05.10.

Érdekes sorozat interval query-k optimalizálásáról

Filed under: Adatbázisok,SQL Server,Szakmai élet — Soczó Zsolt @ 19:16

Messze nem olyan egyszerű az ügy, mint amilyennek elsőre látszik.

Newer Posts »

Powered by WordPress