Re: [rlug] fun with raid and sync
On Fri, 2010-08-06 at 08:40 +0300, Dan Borlovan wrote: On 08/05/2010 11:29 PM, Mircea MITU wrote: La momentul T2, se adauga inapoi discul luat la momentul T1, si de aici incepe partea fun: Nu-mi explic decit daca discul a fost smuls din mers dupa care computerul resetat de la buton si nici atunci Nu s-a intamplat asta. A fost scos dupa shutdown si inainte de pornire :) Inversiunea sda/sdb ar trebui sa apara doar daca ai legat discul pe alt canal, Discul nou ce a devenit sda a fost conectat in portul sata3 le ia in ordinea canalelor sata si la raid i se cam rupe de cum le cheama, provided ca exista in mdadm.conf cu uuid-urile corecte si nu se fac smecherii manuale prin init script-uri In sistemele de acuma dupa ce-ti pui raid-urile pe picioare iti generezi un mdadm.conf bazat pe ce zice mdadm --detail --scan dupa care un update la initramfs ca sa ajunga si acolo informatia Asta a facut-o automat installerul Linux-ului Daca vrei sa faci chestii din astea (in scop de backup) poate ar fi bine sa faci intii mdadm --fail --remove cu toate ariile care folosesc discul de scos si format :) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fun with raid and sync
On Fri, 2010-08-06 at 00:39 +0300, Manuel lonely wolf Wolfshant wrote: - logica de sync este: discul cu timestamp mai recent e sursa de sync corect - biosul a ales pt boot disc-ul celalalt posibil, desi asta ar trebui sa fie constant in timp, daca nu se fac modificari in configurarea BIOS nu exclud posibilitatea ca la momentul T1, portul sata al discului ramas in functiune sa-l fi schimbat, insa era vazut ca sda - grub, la boot, scrie ceva (i.e butez) pe disc-ul de pe care booteaza initial am vrut sa scriu din cite stiu eu grub nu scrie pe disc decit la instalare. apoi mi-am amintit ca grub stie de fallback. doar ca informatia respectiva ar trebui sa fie stocata in /boot, deci nu ar fi trebuit sa afecteze celalalt raid. - astfel, discul devine mai recent si sursa pt sync array n-ar trebui sa se intimple... - partitiile din md1 nu au fost modificate la boot si se sincronizeaza in ordinea fireasca iar daca data de pe sistem nu era mucificata la momentul T1 ( a.i. T1 sa para anterior lui T0) nu era efectul vazut de tine pare bug. ar fi interesant de stiut ce versiuni de kernel si grub erau in uz. 2.6.32 (2.6.32-23-server #37-Ubuntu si 2.6.32-24-server #...-Ubuntu) grub2 (1.98-1ubuntu7) distro: ubuntu 10.04 64bit ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fun with raid and sync
2010/8/6 Mircea MITU mir...@sigu.ro: On Fri, 2010-08-06 at 00:39 +0300, Manuel lonely wolf Wolfshant wrote: - logica de sync este: discul cu timestamp mai recent e sursa de sync corect - biosul a ales pt boot disc-ul celalalt posibil, desi asta ar trebui sa fie constant in timp, daca nu se fac modificari in configurarea BIOS nu exclud posibilitatea ca la momentul T1, portul sata al discului ramas in functiune sa-l fi schimbat, insa era vazut ca sda - grub, la boot, scrie ceva (i.e butez) pe disc-ul de pe care booteaza initial am vrut sa scriu din cite stiu eu grub nu scrie pe disc decit la instalare. apoi mi-am amintit ca grub stie de fallback. doar ca informatia respectiva ar trebui sa fie stocata in /boot, deci nu ar fi trebuit sa afecteze celalalt raid. - astfel, discul devine mai recent si sursa pt sync array n-ar trebui sa se intimple... - partitiile din md1 nu au fost modificate la boot si se sincronizeaza in ordinea fireasca iar daca data de pe sistem nu era mucificata la momentul T1 ( a.i. T1 sa para anterior lui T0) nu era efectul vazut de tine pare bug. ar fi interesant de stiut ce versiuni de kernel si grub erau in uz. 2.6.32 (2.6.32-23-server #37-Ubuntu si 2.6.32-24-server #...-Ubuntu) grub2 (1.98-1ubuntu7) friday flame distro: ubuntu 10.04 64bit Aha, cred ca am gasit problema! /friday flame ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fun with raid and sync
2010/8/5 Mircea MITU mir...@sigu.ro: Ehlo, se dau doua discuri cu 2 partitii fiecare si raid 1 software (mdadm) intre ele, ce la momentul T0 arata astfel: md0: sda1, sdb1 - sistem de operare (inclusiv /boot) md1: sda2, sdb2 - date Fiind raid 1 software si /boot e md0, grub e instalat pe ambele discuri La momentul T1, se scoate fizic un disc din ele, se pune deoparte (neutilizat) si sistemul/raid-ul merge cu un singur disc. in acest moment (T1) raidul arata: md0: sda1/_ md1: sda2/_ La momentul T2, se adauga inapoi discul luat la momentul T1, si de aici incepe partea fun: - sda de la T1 devine sdb in T2 - noul disc devine sda - md0 isi face sync: sda - sdb - md1 isi face sync: sdb - sda Efectul imediat a fost mucificarea partiala a partitiei sda1 (T1). Daca exista vreo minte mai luminata si mai limpede decat a mea, imi poate explica de ce anume s-a produs acest fenomen si cum anume se poate evita pe viitor? Singura explicatie ce mi-o pot da este: - logica de sync este: discul cu timestamp mai recent e sursa de sync - biosul a ales pt boot disc-ul celalalt - grub, la boot, scrie ceva (i.e butez) pe disc-ul de pe care booteaza - astfel, discul devine mai recent si sursa pt sync array - partitiile din md1 nu au fost modificate la boot si se sincronizeaza in ordinea fireasca Nota: nu-s vreun expert in md, dar zic din cargo-cultingul adunat in timp. Posibil sa ma insel. - md n-are absolut nici o treaba cu numele de tip sdXY, device-urile au metadate scrise pe ele (la sfarsit) care contin uuid-ul lor si uuid-ul device-ului md. Pot fi asamblate doar pe baza acestor informatii; - mdadm --query/detai/examine device sunt mari prieteni cu asamblorii de md-uri - e _foarte_ indicat ca atunci cand scoti un disc din raid (si nu intentionezi sa-l mai folosesti drept sursa de date pt. sync) sa-l marchezi ca failed, tocmai ca sa nu se intample ce ai zis tu mai sus -re: instalare grub pe ambele discuri, recomand urmatoarea reteta (yeah, more cargo-culting): shell$ grub --no-floppy grub device (hd0) /dev/sda grub root (hd0,0) grub setup (hd0) grub device (hd0) /dev/sdb grub root (hd0,0) grub setup (hd0) grub ^C Dracia de mai sus asigura ca orice disc ar fi vazut de bios ca discul de boot, sa-si incarce stage2, kernelul si initrd-ul de pe membrul raid de pe acelasi disc. Inteleg ca gruburi ceva mai noi fac ce trebuie la grub-install /dev/md0, dar n-as paria pe asta. - grub nu scrie nimic pe discul care booteaza, altfel s-ar invalida raidurile 1 la orice boot (ma rog ar fi savedefault dar ala se pune in mbr din cate stiu, si in orice caz, nu stie el de metadatele de raid incat sa schimbe vreun mtime pe-acolo). Sa rezum pt. cei cu tl;dr syndrome: parerea mea e ca e de la lipsa de mdadm --fail. -- Petre. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] php accellerator (si mai mult de atat) - alternative la zend
On Friday 06 August 2010 06:10:51 Flower wrote: On 08/04/2010 01:36 PM, Alex 'CAVE' Cernat wrote: in schimb apc plus fastcgi (orice varianta) sucks, teoretic merge (dar la fel zici ca si dacia e masina) Te rog detaliază partea asta. Am php-fastcgi + apc și merge de la caz la caz cam de 3-5 ori mai bine decât fără. Dar de ce nu zice nimeni nimic de eaccelerator? Ce aveti impotriva lui? Eu am php-fastcgi + eaccelerator. E drept, nu am facut benchmarks sa vad cum sta treaba. -- Claudiu Nicolaie CISMARU GNU GPG Key: http://claudiu.targujiu.net/key.gpg T: +40 755 135455 E: clau...@virtuamagic.com, claudiu.cism...@gmail.com signature.asc Description: This is a digitally signed message part. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fun with raid and sync
On Fri, 2010-08-06 at 09:50 +0300, Petru Ratiu wrote: Sa rezum pt. cei cu tl;dr syndrome: parerea mea e ca e de la lipsa de mdadm --fail. Atunci de ce o partitie se sincroniza intr-un sens si cealalata in celalalt sens? md0: sda1 - sdb1 md1: sda2 - sdb2 ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fun with raid and sync
On 08/06/2010 11:19 AM, Petru Ratiu wrote: Eu zic ca intre T1 si T2 a mai fost un moment T1.9 in care cineva a incercat sa porneasca unul din md-uri cu discul gresit. Dar cum ziceam, daca se dadea fail de la inceput pe device-urile gresite, nu le mai folosea drept sursa de biti. Dar daca discul ramas in matrice se stica, cum refaci matricea de pe discul din dulap, daca l-ai marcat fail? -- Teddy ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fun with raid and sync
On 08/06/2010 11:46 AM, Petru Ratiu wrote: 2010/8/6 Tudor Gheorghete...@bvnet.ro: On 08/06/2010 11:19 AM, Petru Ratiu wrote: Eu zic ca intre T1 si T2 a mai fost un moment T1.9 in care cineva a incercat sa porneasca unul din md-uri cu discul gresit. Dar cum ziceam, daca se dadea fail de la inceput pe device-urile gresite, nu le mai folosea drept sursa de biti. Dar daca discul ramas in matrice se stica, cum refaci matricea de pe discul din dulap, daca l-ai marcat fail? Why would you do this? Si pentru ca n-am timp de subtilitati, e o idee _extrem_ de proasta sa folosesti un raid degradat pe post de backup. De ce degradat? Ai facut matricea, si pe urma il pui in dulap la pastrare. Deci este la fel de bun ca cel ramas in PC. -- Teddy ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fun with raid and sync
On Fri, 2010-08-06 at 11:19 +0300, Petru Ratiu wrote: 2010/8/6 Mircea MITU mir...@sigu.ro: On Fri, 2010-08-06 at 09:50 +0300, Petru Ratiu wrote: Sa rezum pt. cei cu tl;dr syndrome: parerea mea e ca e de la lipsa de mdadm --fail. Atunci de ce o partitie se sincroniza intr-un sens si cealalata in celalalt sens? md0: sda1 - sdb1 md1: sda2 - sdb2 Eu zic ca intre T1 si T2 a mai fost un moment T1.9 in care cineva a incercat sa porneasca unul din md-uri cu discul gresit. Dar cum ziceam, daca se dadea fail de la inceput pe device-urile gresite, nu le mai folosea drept sursa de biti. Nu exclud asta. Intrebarea mea ramane totusi: care e logica de sync a matricii raid? ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fun with raid and sync
2010/8/6 Tudor Gheorghe te...@bvnet.ro: On 08/06/2010 11:46 AM, Petru Ratiu wrote: 2010/8/6 Tudor Gheorghete...@bvnet.ro: On 08/06/2010 11:19 AM, Petru Ratiu wrote: Eu zic ca intre T1 si T2 a mai fost un moment T1.9 in care cineva a incercat sa porneasca unul din md-uri cu discul gresit. Dar cum ziceam, daca se dadea fail de la inceput pe device-urile gresite, nu le mai folosea drept sursa de biti. Dar daca discul ramas in matrice se stica, cum refaci matricea de pe discul din dulap, daca l-ai marcat fail? Why would you do this? Si pentru ca n-am timp de subtilitati, e o idee _extrem_ de proasta sa folosesti un raid degradat pe post de backup. De ce degradat? Ai facut matricea, si pe urma il pui in dulap la pastrare. Deci este la fel de bun ca cel ramas in PC. A, deci le pui pe amandoua in dulap? -- Petre poate sunt eu prost si nu inteleg ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fun with raid and sync
On 08/06/2010 11:56 AM, Petru Ratiu wrote: Dar daca discul ramas in matrice se stica, cum refaci matricea de pe discul din dulap, daca l-ai marcat fail? Why would you do this? Si pentru ca n-am timp de subtilitati, e o idee _extrem_ de proasta sa folosesti un raid degradat pe post de backup. De ce degradat? Ai facut matricea, si pe urma il pui in dulap la pastrare. Deci este la fel de bun ca cel ramas in PC. A, deci le pui pe amandoua in dulap? Nu, unul il pun in dulap pt back-up si-l inlocuiesc cu unul nou.Sau las matricea fara un membru. Celalalt disc ramane in pc. -- Teddy ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fun with raid and sync
2010/8/6 Mircea MITU mir...@sigu.ro: On Fri, 2010-08-06 at 11:19 +0300, Petru Ratiu wrote: 2010/8/6 Mircea MITU mir...@sigu.ro: On Fri, 2010-08-06 at 09:50 +0300, Petru Ratiu wrote: Sa rezum pt. cei cu tl;dr syndrome: parerea mea e ca e de la lipsa de mdadm --fail. Atunci de ce o partitie se sincroniza intr-un sens si cealalata in celalalt sens? md0: sda1 - sdb1 md1: sda2 - sdb2 Eu zic ca intre T1 si T2 a mai fost un moment T1.9 in care cineva a incercat sa porneasca unul din md-uri cu discul gresit. Dar cum ziceam, daca se dadea fail de la inceput pe device-urile gresite, nu le mai folosea drept sursa de biti. Nu exclud asta. Intrebarea mea ramane totusi: care e logica de sync a matricii raid? http://lxr.linux.no/#linux+v2.6.35/drivers/md/dm-raid1.c#L327 Din cate imi dau seama, default_mirror e salvat in metadatele matricii, vad la un mdadm --detail /dev/md0 ca am un camp preferred mirror. (sorry ca n-am sapat mai mult, cunostintele mele de C sunt minimale). -- Petre. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fun with raid and sync
2010/8/6 Tudor Gheorghe te...@bvnet.ro: On 08/06/2010 11:56 AM, Petru Ratiu wrote: Dar daca discul ramas in matrice se stica, cum refaci matricea de pe discul din dulap, daca l-ai marcat fail? Why would you do this? Si pentru ca n-am timp de subtilitati, e o idee _extrem_ de proasta sa folosesti un raid degradat pe post de backup. De ce degradat? Ai facut matricea, si pe urma il pui in dulap la pastrare. Deci este la fel de bun ca cel ramas in PC. A, deci le pui pe amandoua in dulap? Nu, unul il pun in dulap pt back-up si-l inlocuiesc cu unul nou.Sau las matricea fara un membru. Celalalt disc ramane in pc. Asaaa, si un raid cu un membru lipsa sau desincronizat se numeste? Degradat cumva? Facem rollback sa discutam de ce e o idee proasta, acum ca ne-am lamurit cum se cheama? -- Petre why did it have to be Friday? ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] php accellerator (si mai mult de atat) - alternative la zend
Dar de ce nu zice nimeni nimic de eaccelerator? Ce aveti impotriva lui? Poate pentru ca nu e thread safe http://neosmart.net/blog/2007/eaccelerator-php-extension-isnt-thread-safe/:) -- Message made from 100% recycled electrons. http://www.lamp.ro http://www.regex.ro http://www.nethelp.ro ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fun with raid and sync
On 08/06/2010 12:08 PM, Petru Ratiu wrote: 2010/8/6 Tudor Gheorghete...@bvnet.ro: On 08/06/2010 11:56 AM, Petru Ratiu wrote: Dar daca discul ramas in matrice se stica, cum refaci matricea de pe discul din dulap, daca l-ai marcat fail? Why would you do this? Si pentru ca n-am timp de subtilitati, e o idee _extrem_ de proasta sa folosesti un raid degradat pe post de backup. De ce degradat? Ai facut matricea, si pe urma il pui in dulap la pastrare. Deci este la fel de bun ca cel ramas in PC. A, deci le pui pe amandoua in dulap? Nu, unul il pun in dulap pt back-up si-l inlocuiesc cu unul nou.Sau las matricea fara un membru. Celalalt disc ramane in pc. Asaaa, si un raid cu un membru lipsa sau desincronizat se numeste? Degradat cumva? Facem rollback sa discutam de ce e o idee proasta, acum ca ne-am lamurit cum se cheama? Ai dreptate. -- Teddy ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] php accellerator (si mai mult de atat) - alternative la zend
Te rog detaliază partea asta. Am php-fastcgi + apc și merge de la caz la caz cam de 3-5 ori mai bine decât fără. Nu cred ca sux neaparat si rau nici atat nu cred ca face. Pt iluminare cititi aci: http://stackoverflow.com/questions/598444/how-to-share-apc-cache-between-several-php-processes-when-running-under-fastcgi Total de acord, merge mai bine decat fara, dar ar fi mers si mai bine daca ar putea fi folosita share-uirea memoriei din apc-uri. Bine, ar merge share-uita daca lasi php-ul sa se ocupe de alocarea proceselor, dar din ce-am citit (ce-i drept, n-am testat) apar destul de des probleme, fata de varianta gestionarii proceselor de php din daemonul de fast cgi. Asa ca momentan fiecare proces de php are apc-ul lui care cache-uieste. De aia cam suxx, ca ocupa aiurea memorie. Dar in rest se misca foarte bine si oricum duce mult mai mult decat php chior plus apc. Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] php accellerator (si mai mult de atat) - alternative la zend
On 08/06/2010 03:44 PM, Alex 'CAVE' Cernat wrote: Total de acord, merge mai bine decat fara, dar ar fi mers si mai bine daca ar putea fi folosita share-uirea memoriei din apc-uri. Bine, ar merge share-uita daca lasi php-ul sa se ocupe de alocarea proceselor, dar din ce-am citit (ce-i drept, n-am testat) apar destul de des probleme, fata de varianta gestionarii proceselor de php din daemonul de fast cgi. Asa ca momentan fiecare proces de php are apc-ul lui care cache-uieste. De aia cam suxx, ca ocupa aiurea memorie. Dar in rest se misca foarte bine si oricum duce mult mai mult decat php chior plus apc. Mda, nu știu de ce face asta, probabil încearcă să fie safe. Oricum e clar că-și face treaba cu vârf și îndesat: Hits: 17490066 (100%) Misses: 3126 (0%) ceea ce pentru mine este relevant. Iar memorie consumă atât cât îi dau voie adică: Free: 191.7 MBytes (53.3%) Used: 168.3 MBytes (46.7%) E cam fragmentată memoria: Fragmentation: 15.32% ( 29.4 MBytes out of 191.7 MBytes in 906 fragments) dar nu cred că mă deranjează în mod personal, cel puțin nu deocamdată :) Uptime 12 days, 7 hours and 39 minutes Flower -- http://tech.serafimpantea.ro/ ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] php accellerator (si mai mult de atat) - alternative la zend
On 8/6/2010 4:17 PM, Flower wrote: On 08/06/2010 03:44 PM, Alex 'CAVE' Cernat wrote: Total de acord, merge mai bine decat fara, dar ar fi mers si mai bine daca ar putea fi folosita share-uirea memoriei din apc-uri. Bine, ar merge share-uita daca lasi php-ul sa se ocupe de alocarea proceselor, dar din ce-am citit (ce-i drept, n-am testat) apar destul de des probleme, fata de varianta gestionarii proceselor de php din daemonul de fast cgi. Asa ca momentan fiecare proces de php are apc-ul lui care cache-uieste. De aia cam suxx, ca ocupa aiurea memorie. Dar in rest se misca foarte bine si oricum duce mult mai mult decat php chior plus apc. Tu cum il folosesti ? In varianta de management de procese din fastcgi (aka fiecare php are apc-ul cu memoria lui) ? Sau varianta php-ul isi face singur managementul (si e o singura memorie share-uita alocata) ? Alex Mda, nu știu de ce face asta, probabil încearcă să fie safe. Oricum e clar că-și face treaba cu vârf și îndesat: Hits: 17490066 (100%) Misses: 3126 (0%) ceea ce pentru mine este relevant. Iar memorie consumă atât cât îi dau voie adică: Free: 191.7 MBytes (53.3%) Used: 168.3 MBytes (46.7%) E cam fragmentată memoria: Fragmentation: 15.32% ( 29.4 MBytes out of 191.7 MBytes in 906 fragments) dar nu cred că mă deranjează în mod personal, cel puțin nu deocamdată :) Uptime 12 days, 7 hours and 39 minutes Flower ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] php accellerator (si mai mult de atat) - alternative la zend
On 08/06/2010 04:25 PM, Alex 'CAVE' Cernat wrote:
Tu cum il folosesti ? In varianta de management de procese din
fastcgi (aka fiecare php are apc-ul cu memoria lui) ? Sau varianta
php-ul isi face singur managementul (si e o singura memorie
share-uita alocata) ?
*Presupun* că e prima variantă.
# cat /etc/init.d/php-fastcgi
#!/bin/bash
BIND=127.0.0.1:9000
USER=apache
PHP_FCGI_CHILDREN=10
PHP_FCGI_MAX_REQUESTS=1000
PHP_CGI=/usr/bin/php-cgi
PHP_CGI_NAME=`basename $PHP_CGI`
PHP_CGI_ARGS=- USER=$USER PATH=/usr/bin
PHP_FCGI_CHILDREN=$PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=$PHP_FCGI_MAX_REQUESTS $PHP_CGI -b $BIND
RETVAL=0
start() {
echo -n Starting PHP FastCGI:
start-stop-daemon --quiet --start --background --chuid $USER
--exec /usr/bin/env -- $PHP_CGI_ARGS
RETVAL=$?
echo $PHP_CGI_NAME.
}
stop() {
echo -n Stopping PHP FastCGI:
killall -q -w -u $USER $PHP_CGI
RETVAL=$?
echo $PHP_CGI_NAME.
}
case $1 in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
*)
echo Usage: php-fastcgi {start|stop|restart}
exit 1
;;
esac
exit $RETVAL
Sau trebuie să mă uit în altă parte?
Flower
--
http://tech.serafimpantea.ro/
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] php accellerator (si mai mult de atat) - alternative la zend
Nope, e varianta a doua, vezi portiunea de bold.
Si daca tot il folosesti asa, ce fel de feedback poti sa dai ?
Alex
Tu cum il folosesti ? In varianta de management de procese din
fastcgi (aka fiecare php are apc-ul cu memoria lui) ? Sau varianta
php-ul isi face singur managementul (si e o singura memorie
share-uita alocata) ?
*Presupun* că e prima variantă.
# cat /etc/init.d/php-fastcgi
#!/bin/bash
BIND=127.0.0.1:9000
USER=apache
*PHP_FCGI_CHILDREN=10*
PHP_FCGI_MAX_REQUESTS=1000
PHP_CGI=/usr/bin/php-cgi
PHP_CGI_NAME=`basename $PHP_CGI`
PHP_CGI_ARGS=- USER=$USER PATH=/usr/bin
PHP_FCGI_CHILDREN=$PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=$PHP_FCGI_MAX_REQUESTS $PHP_CGI -b $BIND
RETVAL=0
start() {
echo -n Starting PHP FastCGI:
start-stop-daemon --quiet --start --background --chuid $USER
--exec /usr/bin/env -- $PHP_CGI_ARGS
RETVAL=$?
echo $PHP_CGI_NAME.
}
stop() {
echo -n Stopping PHP FastCGI:
killall -q -w -u $USER $PHP_CGI
RETVAL=$?
echo $PHP_CGI_NAME.
}
case $1 in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
*)
echo Usage: php-fastcgi {start|stop|restart}
exit 1
;;
esac
exit $RETVAL
Sau trebuie să mă uit în altă parte?
Flower
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] php accellerator (si mai mult de atat) - alternative la zend
De fapt cred ca sunt mai multe diferente decat m-am gandit la prima
vedere, pentru ca la tine vad ca fastcgi-ul e complet separat de apache.
Eu mai devreme ma refeream la mod_fcgid, care are configuratii foarte
asemanatoare, dar care face singur managementul proceselor de php-cgi
(daca alegi varianta de configurare recomandata). Ce-i drept, parca nu
mai ai libertatea de a muta cu totul php-ul pe alta masina.
Alex
On 8/6/2010 5:15 PM, Alex 'CAVE' Cernat wrote:
Nope, e varianta a doua, vezi portiunea de bold.
Si daca tot il folosesti asa, ce fel de feedback poti sa dai ?
Alex
Tu cum il folosesti ? In varianta de management de procese din
fastcgi (aka fiecare php are apc-ul cu memoria lui) ? Sau varianta
php-ul isi face singur managementul (si e o singura memorie
share-uita alocata) ?
*Presupun* că e prima variantă.
# cat /etc/init.d/php-fastcgi
#!/bin/bash
BIND=127.0.0.1:9000
USER=apache
*PHP_FCGI_CHILDREN=10*
PHP_FCGI_MAX_REQUESTS=1000
PHP_CGI=/usr/bin/php-cgi
PHP_CGI_NAME=`basename $PHP_CGI`
PHP_CGI_ARGS=- USER=$USER PATH=/usr/bin
PHP_FCGI_CHILDREN=$PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=$PHP_FCGI_MAX_REQUESTS $PHP_CGI -b $BIND
RETVAL=0
start() {
echo -n Starting PHP FastCGI:
start-stop-daemon --quiet --start --background --chuid $USER
--exec /usr/bin/env -- $PHP_CGI_ARGS
RETVAL=$?
echo $PHP_CGI_NAME.
}
stop() {
echo -n Stopping PHP FastCGI:
killall -q -w -u $USER $PHP_CGI
RETVAL=$?
echo $PHP_CGI_NAME.
}
case $1 in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
*)
echo Usage: php-fastcgi {start|stop|restart}
exit 1
;;
esac
exit $RETVAL
Sau trebuie să mă uit în altă parte?
Flower
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] php accellerator (si mai mult de atat) - alternative la zend
On 08/06/2010 05:23 PM, Alex 'CAVE' Cernat wrote: De fapt cred ca sunt mai multe diferente decat m-am gandit la prima vedere, pentru ca la tine vad ca fastcgi-ul e complet separat de apache. Eu mai devreme ma refeream la mod_fcgid, care are configuratii foarte asemanatoare, dar care face singur managementul proceselor de php-cgi (daca alegi varianta de configurare recomandata). Ce-i drept, parca nu mai ai libertatea de a muta cu totul php-ul pe alta masina. Hmmm, e posibil să fie complet separat de apache pentru că... îl folosesc pe nginx :) Dacă ai nevoie de ceva date suplimentare pls spune unde să caut că nu-s mare meșter în web/php. But keen to learn :) Flower -- http://tech.serafimpantea.ro/ ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] php accellerator (si mai mult de atat) - alternative la zend
Acum 1-2 ani cand am facut niste teste, eaccelerator era cel mai
rapid, apc era pe locul 2. Zend este si encoder, si din cauza asta
pierdea destul de mult la viteza (scriptul encodat era chiar un pic
mai lent decat scriptul raw fara encodare).
APC-ul iti ofera niste functii pentru caching, dar trebuie gandita
aplicatia pe care vrei sa o accelerezi din start sa le foloseasca.
Oricum, nu mai am datele testelor.
Dar esti sigur ca aplicatia ta are nevoie de accelerare pe partea de
script si nu de baza de date? de obicei lucrul cu baza de date e cel
care tine aplicatia pe loc.
2010/8/6 Alex 'CAVE' Cernat c...@cernat.ro:
De fapt cred ca sunt mai multe diferente decat m-am gandit la prima
vedere, pentru ca la tine vad ca fastcgi-ul e complet separat de apache.
Eu mai devreme ma refeream la mod_fcgid, care are configuratii foarte
asemanatoare, dar care face singur managementul proceselor de php-cgi
(daca alegi varianta de configurare recomandata). Ce-i drept, parca nu
mai ai libertatea de a muta cu totul php-ul pe alta masina.
Alex
On 8/6/2010 5:15 PM, Alex 'CAVE' Cernat wrote:
Nope, e varianta a doua, vezi portiunea de bold.
Si daca tot il folosesti asa, ce fel de feedback poti sa dai ?
Alex
Tu cum il folosesti ? In varianta de management de procese din
fastcgi (aka fiecare php are apc-ul cu memoria lui) ? Sau varianta
php-ul isi face singur managementul (si e o singura memorie
share-uita alocata) ?
*Presupun* că e prima variantă.
# cat /etc/init.d/php-fastcgi
#!/bin/bash
BIND=127.0.0.1:9000
USER=apache
*PHP_FCGI_CHILDREN=10*
PHP_FCGI_MAX_REQUESTS=1000
PHP_CGI=/usr/bin/php-cgi
PHP_CGI_NAME=`basename $PHP_CGI`
PHP_CGI_ARGS=- USER=$USER PATH=/usr/bin
PHP_FCGI_CHILDREN=$PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=$PHP_FCGI_MAX_REQUESTS $PHP_CGI -b $BIND
RETVAL=0
start() {
echo -n Starting PHP FastCGI:
start-stop-daemon --quiet --start --background --chuid $USER
--exec /usr/bin/env -- $PHP_CGI_ARGS
RETVAL=$?
echo $PHP_CGI_NAME.
}
stop() {
echo -n Stopping PHP FastCGI:
killall -q -w -u $USER $PHP_CGI
RETVAL=$?
echo $PHP_CGI_NAME.
}
case $1 in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
*)
echo Usage: php-fastcgi {start|stop|restart}
exit 1
;;
esac
exit $RETVAL
Sau trebuie să mă uit în altă parte?
Flower
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug
--
THE END of this transmission
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug
