Vlákno názorů k článku
Microsoft SQL server pro Linux release candidate
od Kernel Manic - Tak horky to jeste nebude (na 32GB masine,...
-
No jo. Ve Windows když dojde paměť, tak to OS zahlásí, a aplikace si s tím může poradit. Na AIXu přijde SIGDANGER, a aplikace si s tím může poradit. Akorát na Linuxu se OS tváří že je všechno OK, alokuje se, alokuje se... a najednou když proces přistoupí k alokované paměti, tak se začnou losovat a odstřelovat procesy. To se pak nedivte.
-
Kernel Manic (neregistrovaný)
Neco na tom mozna bude, na 16GB Win Servru 2012R2 ten samy import z Oracle nepadl. Ale spise bych rek ze to je takova hra Microsoftu. Tu mate linux verzi, zjistite ze je naprd a nasadite radeji Win Server :) Ono uz kdyz jsme u toho Oraclu tak windows verze je taky nejak lepsi nez ta linuxova...
-
Oracle jsem používal na AIXu, HP-UX, Solarisu i Windows, ale na Linuxu jen velmi málo, takže to nesrovnám. Pamatuju si, že Windows i Solarisu byl schopen vyhodit hlášku o selhání alokace paměti.
Posouzení použitelnosti MS SQL Serveru na Linuxu bych si nechal po finálním vydání, a nějakém dalším roce nebo dvou na vychytání bugů. Portovat z Windows s jejich obrovským API a velmi kvalitním kernelem na cokoliv jiného je určitě dost výzva. A souhlasím že je otázka, jakou má MS motivaci.
-
NT není špatný kernel. Jestli je něco "velmi kvalitní" je subjektivní, ale rozhodně je dostatečně schopný. Některé věci má vyřešené líp, než Linux (např právě ta alokace paměti, nebo systematické používání ACL namísto výchozího idiotského unixového modelu), v jiných za Linuxem zaostává (např. IO a podpora SMP). NT má lepší rozhraní pro ovladače (respektive narozdíl od Linuxu má rozhraní pro ovladače), Linux má zase lepší VFS. Spíš než kernel je na Windows děsivé to Win32 API... tím ovšem nechci říct, že by POSIX byl kdovíjak lepší.
-
S výše uvedeným názorem z velké části souhlasím a podstatu obou OS dobře shrnuje. Dave Cutler předvedl po tom, co mu u DECu nepovolili vývoj nového OS a spolupráci na CPU a získal ho Microsoft, mistrovské dílo a architektura ovladačů na bázi IRP včetně možnosti relativně levného stackování (při založení vyhrazený prostor v hlavičce paketu) je velmi pěkná a Linux se vlastně dlouhodobě snaží tuto úroveň asynchronizmu zpětně do architektury zavést. Ovšem dělá to specificky pro jednotlivé subsystémy BIO, sk_buff a postupné přidávání operací do file_operations (historické fasync, writev, readv a postupně přechod na generický read_iter/write_iter a kiocb). To poslední se již začíná IRP hodně blížit, ale jeho obecnost nemá. Ovšem díky postupnému přidávání operací a nutnosti i celé složitější a zásadnější drivery filesystémů a na výkon kritických zařízení postupně celkem zásadním způsobem přepisovat dochází k procesu typu simulated annealing a celkově to vede pro používané a aktivně spravované subsystémy k přechodu na moderní koncepci programování (RCU, lockfree, blockfree atd.). I to, že není definované jedno, po desítky let v podstatě neměnné IRP pro veškeré subsystémy, ale každý přichází s metodou optimalizovanou na konkrétní účel a postupně se sjednocují je sice na jednu stranu plýtvání silami vývojářů, ale konečný výsledek může být lepší než na počátku velmi dobře od navržený a fixovaný koncept.
Mám pocit, že na masivním SMP již jádro Linuxu tyto výhody a jasné vedení předvádí. Jsem ale zaměřený spíš na embedded a bechmarkováním propustnosti se neživím, takže to může být mylný dojem. Na druhou stranu pro RT upravená jádra na slabším ARM HW je dosažení maximálních latencí 300 usec třeba pro přenos CAN zpráv z kódu generovaného z Matlabu/Simulinku na sběrnici a analyzátor s časovým známkování i při plné zátěži OS vším možným celkem pěkný výsledek. V podstatě "zaručený/spolehlivý" výstup na IO piny je na tom ještě lépe.
Jinak návrh ovladačů a jejich údržba pro nekritická zařízení není na Linuxu až tak velký problém. Spravuji nějaké drivery (bohužel pro nedostatek sil a uživatelů mimo hlavní strom) někdy od verze 1.4 nebo 2.0 s tím, že teoreticky je lze stále zkompilovat pro všechny verze jádra. Prakticky by to mohlo i včetně USB a PCI být použitelné ještě někde od 2.4. A postupně se API stabilizuje. Poslední úpravy pro udržení kompatibility provedené v letech 2008, 2009 a 2011 jsou spíše kosmetické, kdy jádro přidává makra/funkce, aby se kódu psalo méně. Přitom pokud by se drivery přepsaly s využitím aktuálních pomůcek pro zjednodušení, tak by se ještě výrazně pročistily a zkrátily. Takže by to bylo jen dobře.
Na Windows je teoretickou výhodou, že ten stejný ovladač ovladač, o kterém se bavím na Linuxu, lze teoreticky vzít z verze pro NT 3.5 a pustit ve Windows 10. Prakticky to ale možné není, zaprvé i v relativně minimu support funkcí dostupných pro ovladače ve Windows kernel API knihovnách byly chyby (špatné bariéry v InterlockedExchange atd.), zadruhé je celý model servisních IRP požadavků PnP a power managementu rozšířený a několikrát se změnilo pořadí volání a především pravidla, co se ve kterém smí udělat. Kapitolou samu pro sebe je pak připravit INI file tak, aby ho všechny verze Windows ideálně od 2000 vzaly. Moho věcí pak je na Windows relativně složitých citlivých na zavlečení chyby. Například kancelace IRP při chybě, nedostupnosti dat vyžaduje pěknou magii s IoAcquireCancelSpinLock, který pro SMP a nějaká více zatížená zařízení bude vést k docela zásadním kolizím v řádkách cache všech úrovní. A naprogramovat tuto část spolehlivě je těžké. I když zrovna zde NT jádro nabízí helper s IRP frontami, jehož využití asi hodně pomůže. V současné době máme zrovna s příchodem Windows 10 celkem zásadní problémy s interakcí driveru s Power Managementem, tak pokud nějaký nadšenec do Win NT jádra má chuť předvést své znalosti a nadšení, tak se s ním rád sejdu.
Takže obecně technicky má každé z jader své výhody a v tuto chvíli na celkem podobné technické a výkonnostní úrovni. Osobně se mi ale s Linuxem pracuje lépe a to, že neprogramuji čistě proti (sice relativně dobře) dokumentovanému API černé skříňky, ale mohu propojení svého kódu s jádrem OS vidět ve zdrojové podobě považuji za velkou výhodu. I když pro jednodušší projekty dnes tyto možnost díky týmu React OS nabízí i prostředí jádra Windows. Ale musel to opět udělat někdo jiný než MS a MS moc se zveřejňováním vnitřních API nepomáhá.
-
> IRP...
I v MS si uvědomili, že používání IRP za všech okolností není úplně ta správná cesta, a proto vzniklo Fast I/O, což se hodí pro operace, které nevyžadují od ovladače příliš práce, takže se alokace IRP nevyplatí.
> Na Windows je teoretickou výhodou, že ten stejný ovladač ovladač, o kterém se bavím na Linuxu, lze teoreticky vzít z verze pro NT 3.5 a pustit ve Windows 10.
Spíš bych mluvil o WXP-W10 nebo Vista-W10. Ač překládat s dnešní verzí WDK pro WIndows XP nemusí být zrovna med, ale stále se dá. S INF soubory, power managementem a PnP souhlasím; napsat tyhle věci správně je pěkná fuška (dokumentace není úplně jasná, když se chcete "inspirovat" cizím driverem, zjistíte, že si to každý dělá + po svém a prostě jim to "náhodou" funguje pro jejich typ driveru...). Naštěstí tu pro PnP/powe lze využít WIndows Driver Framework (KMDF/UMDF), pokud není zaměření ovladače příliš unikátní. Na druhou stranu se tím dostanete do většího INF pekla.
Osobě se snažím INF soubory nepoužívat, pokud to jde. I proto, že když při jejich provádění něco selže, tak se pořádně nedá dozvědět, co se stalo a třeba to sdělit uživateli.
-
j (neregistrovaný)
Tak to jiste, na widlich kdyz dojde pamet tak se widle zhroutej projistotu cely. Respektive jejich odezva vzroste na nekonecno ... takze se s tim da delat jedine to, ze ten system nekdo natvrdo vytrhne z elektriky. Dokonce jsou soudruzi v M$ taci retardovani imbecilove, ze si naprosto s klidem ve svym vlastnim system pro svoje vlastni SQL ukradnou tolik RAM, ze se ani spravce toho systemu k tomu systemu neprihlasi ... a je to defaultni chovani. Parada ne?
-
Pokud je nastaven dostatečný limit pro stránkovací soubor, tak se systém jen tak nepoloží (nejsem si jistý, zda se případně nesnaží stránkovací soubor zvětšovat automaticky, když dochází paměť, ale myslím, že jsem to již zažil). Na HDD je swapování, pravda, znát, na SSD (W8.1) s tím mám naopak dobrou zkušenost (vytížené osmijádro, 40 GB virtuální paměti zabráno, fyzické ten stroj má 16 GB... a dalo se s tím slušně pracovat, odezva nebyla špatná).
-
Ivan (neregistrovaný)
Tohle vypada na klasicky memory leak v MS SQL serveru. Coz by zase nebylo tak divny - je to RC.
Pokud jde o ten Oracle, tak ten funguje jako Java JVM, pamet si alokuje pri startu a s tou pameti si pak hospodari podle sveho. Tzn. nikdy by nemel prekrocit limity(SGA/PGA), ktere mu nastavite pri startu. Tim je zaruceno ze db server nikdy nebude swapovat. -
martinus (neregistrovaný)
to sice je, ale byl bych s tim parametrem opatrny ..:
Actions Taken When PGA_AGGREGATE_LIMIT is Exceeded
Parallel queries will be treated as a unit. First, the sessions that are using the most untunable memory will have their calls aborted. Then, if the total PGA memory usage is still over the limit, the sessions that are using the most untunable memory will be terminated.
SYS processes and background processes other than job queue processes will not be subjected to any of the actions described in this section. Instead, if they are using the most untunable memory, they will periodically write a brief summary of their PGA usage to a trace file.
Takze je treba ladit v urcitych pripadech, pokud nechci aby session byla odstrelena ..,ale zatim jsem se s tim nesetkal ... takze OK.
-
X (neregistrovaný)
Ano, tak to je... Pokud se prekroci, sestreli to session dle popisu v dokumentaci, vygeneruje se trace file a přidá záznam do alert logu.
Je to třeba mít správně nadimenzované, ale je to pak ohraničené. Z mých zkušeností databáze občas sestřelují nějakou jednorázovou, neotestovanou prasárnu, kterou tam pustil developer. :)
ČLÁNKY DO MAILU