Apple MacBook Pro – kvalitet – mit ili istina
Dosta ljudi me pita kakvi su mi utisci sa MacBook Pro mašinom sada posle 2 godine … ja neću tu da sada pravim neki review nego .. najstandardnije, informaija koju vozač tramvaja može da razume, da ukratko sumiram…
- lep je
- stabilan je
- operativni sistem je savršen OSX
- brz je
dobro zvuči a … e ček sad da kažemo i zašto ga skoro uopšte ne koristim (osim što imam gomilu desktopa u kući)
- posle 2 godine, baterija mu drži “još malo pa gotovo” … dakle sa ekranom upola osvetljenim i kompom koji ne radi ništa, 30-45min
- nema teorije da normalan čovek, muškarac, ovo drži na kolenima / u krilu i radi … pečeeeeeeeee ko god da je dizajnirao kutiju, obratio je mnogo više pažnje da to lepo izgleda nego da se dobro ladi, dakle nisam merio ali ozdo peče ubija duže od 5min nema šanse da se koristi iz krila
- relativno skoro mi je rikno hard, morao sam da rastavim ceo komp na delove da bi ga zamenio (ok novi modeli imaju to malo bolje rešeno)
- dvd nije narezao za 2 godine NIJEDAN dvd i pre par meseci kada sam probao – rekao je da ne radi (zaprljao se i nije teo da peče disk a i neće svaki da pročita)
sve u svemu … ako izmemo da sam za iste pare mogao da uzmem 30% jaču mašinu, sa 50-100% jačom grafikom, sa svim mlatimudijalnim dodacima (card readeri, fingerprint scaneri i slično) … teško da ću se u budućnosti ponovo prevariti i uzeti apple. Doduše opet, ako bude neko drugi plaćao – ko zna … mnogo je lep, i OSX je za 10 kopalja bolji od windoze i linuxa zajedno ..
Zauzetost InnoDB tablespace-a
InnoDB … odličan storage engine u vlasništvu ORACLE-a, jedini native transakcioni engine u MySQL-u (a toliko frke oko toga da “ORCL” oće da kupi “JAVA” a već je vlasnik najbitnijeg dela) ima osobinu da po default-u, tj ako nije odabrano file-per-table, drži sve tabele u jednom fajlu, tj u nekoliko (taj jedan moze da dobije svoju braću). I taj fajl se NIKADA ne smanjuje… nemamo pojma koji deo tog fajla je iskoršten, koliko naše tabele stvarno zauzimaju mesta, koliko imamo slobodno etc.. Kada uradimo delete iz tabele, taj prostor se posle koristi za neke druge podatke i nikada se ne vraća fajl sistemu (opet, osim ako ne koristimo file per table).
Dakle, kako da saznamo koliko mesta ima u tom tablespace-u, koliko zauzetog, koliko slobodnog?
Prva stvar koja nam treba je InnoDB monitor. Da bi ga upalili potrebno je da kreiramo jednu tabelu:
CREATE TABLE innodb_tablespace_monitor ENGINE=InnoDB;
Ovo neće kreirati nikakvu tabelu već će dojaviti InnoDB-u da kresne innodb monitor. Dotični će se pojaviti u log fajlu i kada u istom primetimo:
================================================
YYMMDD HH:MM:SS INNODB TABLESPACE MONITOR OUTPUT
================================================
možemo da ugasimo InnoDB monitor (tako što ćemo obrisati onu tabelu)
DROP TABLE innodb_tablespace_monitor;
Sada treba da ždraknemo log file i tamo pronađemo:
FILE SPACE INFO: id 0
size #####, free limit ####, free extents ###
ovde nas zanima ova vrednost za size. To će nam reći veličinu tablespace-a u stranicama. Jedna stranica je 16 kilobajta.
Brzo zatim, treba da naiđemo na gomilu podataka o segmentima:
…
SEGMENT id 0 14 space 0; page 2; res 0 used 0; full ext 0
fragm pages 0; free extents 0; not full extents 0: pages 0
SEGMENT id 0 15 space 0; page 2; res 160 used 160; full ext 2
fragm pages 32; free extents 0; not full extents 0: pages 0
SEGMENT id 0 25 space 0; page 2; res 4161 used 4115; full ext 64
fragm pages 1; free extents 0; not full extents 1: pages 18
…
Ako saberemo vrednosti za “used” dobićemo koliko tačno stranica imamo zauzeto u tablespace-u. Naravno ako pomnožimo to sa 16 kilobajta …
Na MySQL Forge možemo naći odličan skript koji će ove podatke o segmentima izvaditi i izmnožiti kako mi ne bi slučajno izgubili koji minut računajući sami …. čemu služe računari ako ne tome…
RHEL 5.4 / CentOS 5.4
Šta reći, krenula je serija postova sa lošim vestima… Ukratko, ako koristite MySQL zaobiđite CentOS / RHEL 5.4 za sada. Drajveri za storage su “smoreni”, CFQ implementacija je bagovita … etc etc.. sve u svemu ljudi imaju probleme sa 50-70% smanjenim performansama (da da, više nego duplo) tako da, za sada, bar još jedno šest meseci ostanite na 5.3
.nemoj konektor 6.x + kompresija = 20x usporenje
Sitan bag za .nemoj platformu .. .nemoj konektor 6 ako mu se upali kompresija uspori rad sa bazom 20 puta.… šta reći, developeri su pojurili da poprave dok se mi ostali ljubitelji .nemoj tehnologije valjamo po podu riknjavajući od smeha … bag je prijavljen, baš da vidimo koliko će našim .nemoj majstorima trebati da ga oprave.
Jedini workaround za sada je gašenje kompresije.
MA NEMOJ!!!
Radeći ovaj posao stvarno se čovek svega nagleda… od sistema na nosačima aviona, sistema za lansiranje raketa u svemir, sistema koji kontrolišu rad mostova, zgrada, krovova … stvari od kojih se čoveku digne kosa na glavi, od kojih ti opadne kosa ili još gore… no, isto tako, nagleda se morona, debila, idijota … a kako ovaj blog ne bi bio samo obrazovnog karaktera već i da može i meni malo da posluži (da se ispraznim) sada ćemo malo pričati o tim moronima (nećemo pričati o tome da ti moroni imaju mnogo veću platu od mene, tebe i verovatno sve vas koji pratite ovaj blog)…
Najstrašnija kategorija morona je: NE UMEM DA ČITAM
Moron dobije grešku:
InnoDB: Error: cannot allocate 68719476736 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 51644329959 bytes. Operating system errno: 12
InnoDB: Check if you should increase the swap file or
InnoDB: ulimits of your operating system.
….
I kuka i plače, frka, ludilo, “neće da mi se digne, zašto” – AJDE, neće a? Poštovani moronu, PIŠE ti u grešci, nemaš rama IDIJOTE, IDI SI KREPAJ!!!
da ne citiram dalje, ima tu grešaka “user pod kojim vaš tralalalalala radi nema pravo da tralalalala” etc etc .. sve lepo piše, al moroni nisu još naučili sva slova…
Sledeća po strašnosti kategorija je: KADA SMO TESTIRALI BILO JE BRZO A SADA JE SPORO
Ova kategorija idijota obično ima ingeniozno objašnjenje svog problema koje se svodi na:
Mi smo radili ozbiljne testove da zaključimo koji je optimalan server za našu aplikaciju i na testovima na našem 8 jezgarnom serveru sa 128G rama i SAN storage-u sa 24 spindla u stripe-u sa bazom od 100M je sve radilo suviše brzo pa smo mi zaključili da nam je za production server dovoljna ova 486 mašina sa 16M rama i MFM diskom od 20MB koji koristi NFS sa one 386 mašine koja glumi file server sa njindonjsima 3.11 i to nam je sad sporije nego što smo izračunali a baza je samo 100G sada!!!
AJDE!!! malo izkarikirano ali vrlo blizu istine, na žalost
Kategorija koja mene lično najviše nervira su moroni koji postavljaju OČIGLEDNA PITANJA
Ova grupa morona postavlja pitanja o očiglednim i naširoko poznatim manama MySQL-a. Dakle to što oni pitaju je opšte mesto a moji favoriti su:
- uradio sam upgrade sa 3.23 na 5.1 i odjednom je sve sporije
- ne rade mi transakcije, koristim MyISAM storage engine
- ovaj upit od 230 redova koji radi join nad 72 tabele od kojih je svaka velika po 1G traje dugo
- prebacili smo data direktorijum na mrežni disk i sada je sve sporije
- insert u tabelu koja ima 235 indeksa je spor
I apsolutni pobednik: Instalirao sam MySQL i pod wmcvare i pod virtual box-om i nikako ne mogu da dobijem performanse koje dobijem na native mašini …
Šta reći nego AJDE!!!
