ERROR 2013 (HY000): Lost connection to MySQL server during query

[Gabor HALASZ]

Na nekem is kijutott a subject, teljesen random. Valami tipp?

***@server:~# dpkg -l | grep mysql
ii libdbd-mysql-perl 2.9003-4
A Perl5 database interface to the MySQL database
ii libmysqlclient12 4.0.24-5
mysql database client library
ii libmysqlclient14 4.1.11-1
mysql database client library
ii mysql-client-4.1 4.1.11-1
mysql database client binaries
ii mysql-common-4.1 4.1.11-1
mysql database common files (e.g. /etc/mysql/my.cnf)
ii mysql-doc-4.1 4.1.10a-1
mysql database documentation (4.1 branch
ii mysql-server-4.1 4.1.11-1
mysql database server binaries
ii php4-mysql 4.3.10-12
MySQL module for php4

dualopterton, 2GB, 2.6.10, de nem hiszem, hogy ezen mulna, mert egy show
status is elohozza.

[Fagyal Csongor]

E,

Post by Gabor HALASZ
Na nekem is kijutott a subject, teljesen random. Valami tipp?
ii libdbd-mysql-perl 2.9003-4 A Perl5 database
interface to the MySQL database
ii libmysqlclient12 4.0.24-5 mysql database
client library
ii libmysqlclient14 4.1.11-1 mysql database
client library
ii mysql-client-4.1 4.1.11-1 mysql database
client binaries
ii mysql-common-4.1 4.1.11-1 mysql database
common files (e.g. /etc/mysql/my.cnf)
ii mysql-doc-4.1 4.1.10a-1 mysql database
documentation (4.1 branch
ii mysql-server-4.1 4.1.11-1 mysql database
server binaries
ii php4-mysql 4.3.10-12 MySQL module for php4
dualopterton, 2GB, 2.6.10, de nem hiszem, hogy ezen mulna, mert egy
show status is elohozza.

Error log nem mond semmit? Szokott.

- Cs.

[Gabor HALASZ]

Post by Fagyal Csongor
Error log nem mond semmit? Szokott.

Nem, akkor sem, ha query hasal el, és akkor sem, ha a show status, de a
legszórakoztatóbb, hogy a shutdown is előhozza :(

[Fagyal Csongor]

E,

Post by Gabor HALASZ

Post by Fagyal Csongor
Error log nem mond semmit? Szokott.

Nem, akkor sem, ha query hasal el, és akkor sem, ha a show status, de
a legszórakoztatóbb, hogy a shutdown is előhozza :(

Hmmm, hat talan strace-szel megprobalhatod elinditani a mysqld-t... de
ahogy a kollega ur irta, celszeru a MySQL AB altal kiadott binarisokat
hasznalni.

- Cs.

[Horváth Ágoston János]

Ez a segfault jele. Csak van egy safe_mysqld script, ami ujrainditja a
mysql-t, ha az meghalt. Production szervereken roppant hasznos.
Nezzel logot.

Amugy celszeru a mysql.com -os binarisokat hasznalni, stabilabbak es
tokig optimalizaltak (ellentetben a shared-i386 debian binarisokkal).

Post by Gabor HALASZ
Na nekem is kijutott a subject, teljesen random. Valami tipp?
ii libdbd-mysql-perl 2.9003-4
A Perl5 database interface to the MySQL database
ii libmysqlclient12 4.0.24-5
mysql database client library
ii libmysqlclient14 4.1.11-1
mysql database client library
ii mysql-client-4.1 4.1.11-1
mysql database client binaries
ii mysql-common-4.1 4.1.11-1
mysql database common files (e.g. /etc/mysql/my.cnf)
ii mysql-doc-4.1 4.1.10a-1
mysql database documentation (4.1 branch
ii mysql-server-4.1 4.1.11-1
mysql database server binaries
ii php4-mysql 4.3.10-12
MySQL module for php4
dualopterton, 2GB, 2.6.10, de nem hiszem, hogy ezen mulna, mert egy show
status is elohozza.
--
_______________________________________________
linux++ mailing list
http://mlf2.linux.rulez.org/mailman/listinfo/linux++

[Gabor HALASZ]

Post by Horváth Ágoston János
Ez a segfault jele. Csak van egy safe_mysqld script, ami ujrainditja a
mysql-t, ha az meghalt. Production szervereken roppant hasznos.

Ez biztos? Mert tcp-n kapcsolódom, és akkor illene a kliensnek mysql
klinsnek leszakadnia, és nem teszi (persze lehet, hogy visszakonnektál
magától, nem tudom, hogy tud-e ilyet).

Post by Horváth Ágoston János
Nezzel logot.

A logban nincs semmi.

Post by Horváth Ágoston János
Amugy celszeru a mysql.com -os binarisokat hasznalni, stabilabbak es
tokig optimalizaltak (ellentetben a shared-i386 debian binarisokkal).

x86_64, mint irtam, de nem hiszem, hogy optimalizációs gond lenne, mert
gyakorlatilag nulla terhelés mellett is ilyen.

[Pallai Roland]

Post by Gabor HALASZ
Na nekem is kijutott a subject, teljesen random. Valami tipp?
ii libdbd-mysql-perl 2.9003-4
A Perl5 database interface to the MySQL database
ii libmysqlclient12 4.0.24-5
mysql database client library
ii libmysqlclient14 4.1.11-1
mysql database client library
ii mysql-client-4.1 4.1.11-1
mysql database client binaries
ii mysql-common-4.1 4.1.11-1
mysql database common files (e.g. /etc/mysql/my.cnf)
ii mysql-doc-4.1 4.1.10a-1
mysql database documentation (4.1 branch
ii mysql-server-4.1 4.1.11-1
mysql database server binaries
ii php4-mysql 4.3.10-12
MySQL module for php4
dualopterton, 2GB, 2.6.10, de nem hiszem, hogy ezen mulna, mert egy show
status is elohozza.

a perl DBI modulon keresztul nekem is jott elo hasonlo hiba mikor 4.1-
re upgradeltem a mysqld -t, a gond az hogy a sarge-os DBD az 4.0 -as
mysqlclient library-hez van forditva amivel a 4.1-es mysqld nem egeszen
sikerult kompatibilisre

sarge:~# ldd /usr/lib/perl5/auto/DBD/mysql/mysql.so
libmysqlclient.so.12 => /usr/lib/libmysqlclient.so.12 (0x4001f000)


a., libmysqlclient14-dev legyen fenn es CPAN -bol ujraperditeni ezt a
kettot:

DBI-1.47
DBD-mysql-2.9004

b., dotdeb csomagok, ok is a legujabb 4.1-es library-hez forditanak

deb http://packages.dotdeb.org ./
deb-src http://sources.dotdeb.org ./



--
dap

[Gabor HALASZ]

Post by Pallai Roland
a perl DBI modulon keresztul nekem is jott elo hasonlo hiba mikor 4.1-
re upgradeltem a mysqld -t, a gond az hogy a sarge-os DBD az 4.0 -as
mysqlclient library-hez van forditva amivel a 4.1-es mysqld nem egeszen
sikerult kompatibilisre

Hajajj....A legszebb az, hogy egy perl írja, és php olvassa :)

Post by Pallai Roland
sarge:~# ldd /usr/lib/perl5/auto/DBD/mysql/mysql.so
libmysqlclient.so.12 => /usr/lib/libmysqlclient.so.12 (0x4001f000)
a., libmysqlclient14-dev legyen fenn es CPAN -bol ujraperditeni ezt a
DBI-1.47
DBD-mysql-2.9004

Ah, ez szimpatikus tipp, a sid is hasonló.

Post by Pallai Roland
b., dotdeb csomagok, ok is a legujabb 4.1-es library-hez forditanak
deb http://packages.dotdeb.org ./
deb-src http://sources.dotdeb.org ./

Majd ezt is megnézem.

[Gabor HALASZ]

Post by Pallai Roland
a., libmysqlclient14-dev legyen fenn es CPAN -bol ujraperditeni ezt a
DBI-1.47
DBD-mysql-2.9004

Úgy tűnik, ez volt a gond, bár a csomagot fordítottam újra...viszont a
4.1-es mysql nem akarja a latin2-t..., úgyhogy downgrade

[Horváth Ágoston János]

Úgy tûnik, ez volt a gond, bár a csomagot fordítottam újra...viszont a
4.1-es mysql nem akarja a latin2-t..., úgyhogy downgrade

Megvaltozott a karakterkezeles, mert utf8 kellett bele.
Amugy erdemes is hasznalni, es soha tobbe a budos eletben nem lesz
gond a karakterkeszlet-encoding-konvertalas-brrr dolgokkal.

Doksit erdemes olvasgatni, ehun:
http://dev.mysql.com/doc/mysql/en/charset-server.html
illetve
http://dev.mysql.com/doc/mysql/en/charset-database.html

Ebbol a kettobol eleg jol kiderul az igazsag.

[Gabor HALASZ]

Post by Horváth Ágoston János

Post by Gabor HALASZ
Úgy tűnik, ez volt a gond, bár a csomagot fordítottam újra...viszont a
4.1-es mysql nem akarja a latin2-t..., úgyhogy downgrade

Megvaltozott a karakterkezeles, mert utf8 kellett bele.
Amugy erdemes is hasznalni, es soha tobbe a budos eletben nem lesz
gond a karakterkeszlet-encoding-konvertalas-brrr dolgokkal.

Nem csak az volt a gond, hanem egyes bellításokat nem akart elfogadni.

Post by Horváth Ágoston János
http://dev.mysql.com/doc/mysql/en/charset-server.html
illetve
http://dev.mysql.com/doc/mysql/en/charset-database.html
Ebbol a kettobol eleg jol kiderul az igazsag.

Igen, olvastam, de nem használt. A latin2 kell a régi adatok miatt, és a
doksi (és a konfig) szerint rámogatott.

[Fagyal Csongor]

Jaaaaaaj bzeg "send" kozben elszallt a Mozilla...

Na akkor meg egyszer, rovidebben... :-(

Post by Gabor HALASZ

Post by Horváth Ágoston János

Post by Gabor HALASZ
Úgy tűnik, ez volt a gond, bár a csomagot fordítottam újra...viszont a
4.1-es mysql nem akarja a latin2-t..., úgyhogy downgrade

Megvaltozott a karakterkezeles, mert utf8 kellett bele.
Amugy erdemes is hasznalni, es soha tobbe a budos eletben nem lesz
gond a karakterkeszlet-encoding-konvertalas-brrr dolgokkal.

Aaaa eppenhogy nem!
Pontosabban _elvileg_ igen...

Post by Gabor HALASZ
Nem csak az volt a gond, hanem egyes bellításokat nem akart elfogadni.

Post by Horváth Ágoston János
http://dev.mysql.com/doc/mysql/en/charset-server.html
illetve
http://dev.mysql.com/doc/mysql/en/charset-database.html
Ebbol a kettobol eleg jol kiderul az igazsag.

Igen, olvastam, de nem használt. A latin2 kell a régi adatok miatt, és
a doksi (és a konfig) szerint rámogatott.

- egyszer:
character-set-server=latin2
collation-server=latin2_hungarian_ci
- masodszor:
set names 'latin2'
vagy
set character_set_results=NULL
vagy
set collation_connection=latin2_hungarian_ci
set character_set_client=latin2
set character_set_results=latin2
- harmadszor:
database, table, column: charset+collation a megfelelo latin2-es
- negyedszer:
ha replikaciod van, akkor az osszes slave-nek ugyanigy kell lennie

Orusz? :-)

- Cs.

[Gabor HALASZ]

Post by Fagyal Csongor
character-set-server=latin2
collation-server=latin2_hungarian_ci
set names 'latin2'
vagy
set character_set_results=NULL
vagy
set collation_connection=latin2_hungarian_ci
set character_set_client=latin2
set character_set_results=latin2

Tökmindegy, mert úgysem volt stabil, másrészt nincs arra időm, hogy
átbogarásszam az egész doksit ilyesmik miatt; ez kissé development szagú
nekem, majd ha eldöntik, akkor implementálom. A 4.0 jó minden varázslat
nélkül.

Post by Fagyal Csongor
Orusz? :-)

Nem, mert ismet ujra kellett forditanom az egesz php-t, mert ugy
el...tak a dependencyket, hogy nem lehet telepiteni, de leforditani sem,
csak egy alapos ujrakonfigolas es alapos control/rules atiras utan.

[Sickboy]

Post by Gabor HALASZ
Nem, mert ismet ujra kellett forditanom az egesz php-t, mert ugy
el...tak a dependencyket, hogy nem lehet telepiteni, de leforditani sem,
csak egy alapos ujrakonfigolas es alapos control/rules atiras utan.

Igy jar, aki deb-bol rakja a php-t.

[p***@apaczai.elte.hu]

Post by Sickboy

Post by Gabor HALASZ
Nem, mert ismet ujra kellett forditanom az egesz php-t, mert ugy
el...tak a dependencyket, hogy nem lehet telepiteni, de leforditani sem,
csak egy alapos ujrakonfigolas es alapos control/rules atiras utan.

Igy jar, aki deb-bol rakja a php-t.

??

[Sickboy]

Post by Sickboy

Post by Gabor HALASZ
Nem, mert ismet ujra kellett forditanom az egesz php-t, mert ugy
el...tak a dependencyket, hogy nem lehet telepiteni, de leforditani sem,
csak egy alapos ujrakonfigolas es alapos control/rules atiras utan.

Igy jar, aki deb-bol rakja a php-t.

??

Ugy latszik mindenki felreertette szukszavu valaszom.
Tehat: szerintem erdemesebb a php forrast letolteni php.net-rol, es azt
egyszeruen az altalunk szuksegesnek talalt configure opciokkal leforditani
(igy eleve tetszes szerint allithatjuk a compile time opciokat,
kihagyhatjuk a szuksegtelen modulokat, illetve eldonthetjuk, hogy mi
legyen shared vagy beleforditva, stb.) , a configure opciokat pedig
gepenkent megtartani, ha jon uj verzio, csak

configure az elmentett opciokkal
make
su -
/etc/init.d/apache stop; make install; /etc/init.d/apache start

done.

(Jo, tudom, van valami nem official deb url, amirol elerheto friss php
(szemben a debian distrokban talalhato oskovulettel), en inkabb forditom
magamnak.)

[KORN Andras]

Post by Sickboy
Ugy latszik mindenki felreertette szukszavu valaszom.
Tehat: szerintem erdemesebb a php forrast letolteni php.net-rol, es azt
egyszeruen az altalunk szuksegesnek talalt configure opciokkal leforditani
(igy eleve tetszes szerint allithatjuk a compile time opciokat,
kihagyhatjuk a szuksegtelen modulokat, illetve eldonthetjuk, hogy mi
legyen shared vagy beleforditva, stb.) , a configure opciokat pedig
gepenkent megtartani, ha jon uj verzio, csak
configure az elmentett opciokkal
make
su -
/etc/init.d/apache stop; make install; /etc/init.d/apache start
done.

En ugy gondolom, altalaban megeri a pluszfaradsagot az, hogy az ember nem
keveri a forrasbol es csomagbol felrakott dolgokat, ha nem muszaj; vagyis
szerintem jobb .deb-et gyartani a php-bol a sajat configure opciokkal. Ugy
tud rola a csomagkezelo, nem lesz gond a dependencykkel, nem upgrade-elunk
veletlenul olyan libraryt amibol az uj verzio esetleg nem lesz jo a
forrasbol felrakott programnak stb.

Guy

[Gabor HALASZ]

Post by KORN Andras
En ugy gondolom, altalaban megeri a pluszfaradsagot az, hogy az ember nem
keveri a forrasbol es csomagbol felrakott dolgokat, ha nem muszaj; vagyis
szerintem jobb .deb-et gyartani a php-bol a sajat configure opciokkal. Ugy
tud rola a csomagkezelo, nem lesz gond a dependencykkel, nem upgrade-elunk
veletlenul olyan libraryt amibol az uj verzio esetleg nem lesz jo a
forrasbol felrakott programnak stb.

Nem tudom eldönteni, hogy a friss php jobb-e, vagy a debian féle
nemannyirafriss, amiben viszont lakik ötvenegynéhány patch.
Ráadásként ha a php engine éppen nem bugos, akkor is ott vannak a phpban
fejlesztők, akik aztán tudnak mindent....

[Sickboy]

Post by Gabor HALASZ

Post by KORN Andras
En ugy gondolom, altalaban megeri a pluszfaradsagot az, hogy az ember nem
keveri a forrasbol es csomagbol felrakott dolgokat, ha nem muszaj; vagyis
szerintem jobb .deb-et gyartani a php-bol a sajat configure opciokkal. Ugy
tud rola a csomagkezelo, nem lesz gond a dependencykkel, nem
upgrade-elunk
veletlenul olyan libraryt amibol az uj verzio esetleg nem lesz jo a
forrasbol felrakott programnak stb.

Persze, ez a szep megoldas, de viszont lenyegesen tobb energiat is
igenyel. Peldaul az altalad emlitett dependency megjeloleshez azt
manualisan meg kell allapitani, kezzel be kell irkalni, stb. Tehat szumma
nem nyered meg. (Tehat pont ami a gond az x forrasbol szerzett debekkel
(peldaul az elso hozzaszolasomat kivalto dependency problema), azt
mindenkinek maganak kell kisakkozni, ha debet akar.)

De rendben, maradjunk annyiban, hogy a kulso forrasbol kesz debkent
letoltott php az, amit ellenjavalltnak tartok.
Ehhez kepest aztan lehet egyszeru (make install), vagy szep (sajat deb)
alternativakat talalni.

Post by Gabor HALASZ
Nem tudom eldönteni, hogy a friss php jobb-e, vagy a debian féle
nemannyirafriss, amiben viszont lakik ötvenegynéhány patch.

En ugy iteltem meg, hogy el tudom. (Mint rendszergazda ES php fejleszto.
De utobbit tarsasagban letagadom. :)
Ha a nemannyirafriss 4.1.2-re gondolsz, akkor sajnos egyertelmu, hogy
melyik a jobb (nem az). Rengeteg, elmult nehany evben fejlesztett (PHP)
kod egyszeruen nem mukodik azon. Sajnos a PHP az egy olyan platform, ami
folyamatosan fejlodik (maga a nyelv, es nem csak ugy ertve, hogy uj
extension-ok vagy fv-k lesznek). Peldaul en, eppen ezert, mindig a
legujabb verziokat hasznalom. (De ezzel nem vagyok egyedul.)

Post by Gabor HALASZ
Ráadásként ha a php engine éppen nem bugos, akkor is ott vannak a phpban
fejlesztők, akik aztán tudnak mindent....

Na hat ez alap problema.
Tehat valojaban ugy kell kezelni az egesz PHP kerdest, hogy ha mar van
mod_php egy webszerveren, akkor az eleve 90% valoszinuseggel run arbitrary
code. (Kivetelnek kb az tekintheto, ha csak experienced, palyafutasuk
soran webapplikaciok hekkelesevel is komolyan foglalkozo fejlesztok
fejlesztik rajta a vallalat core productjat. Meg ez sem garancia, de barmi
ennel kevesebb az veszett fejsze nyele.)

Magyarul szinte mind1, hogy maga a php engine EPPEN bugos-e, tehat az
egesz webszerver kornyezetet ennek figyelembevetelevel kell kialakitani.

Es ez az, amihez nincs rendes support apache-ban (es nem tudok semmi
masrol sem), mert nem tud mod_php-s siteokat kulon UID-kent futtatni.
(Lasd security-l ujra es ujra felmerulo tema.)
Az apache2 perchild (ami majd egyszer lesz) sajnos nem lesz majd egyszer
sem, mert thread-es, es sok "nepszeru" PHP extension (tehat amit sok php
coder a rendszer "reszenek" tart) nem thread-es (es a fejlesztok szerint
nem is lesz az).

PHP hosting meg vagyon love minden fronton.
(Kene mar valami megoldas. Egyszer elkezdtem az apache(1.3) forrast
hackelni (process alapu perchild megoldas celjabol), de mindig elfolyik az
idom mas lyukon. :S )

[Zoltan NAGY]

udv!

Post by Sickboy
PHP hosting meg vagyon love minden fronton.
(Kene mar valami megoldas. Egyszer elkezdtem az apache(1.3) forrast
hackelni (process alapu perchild megoldas celjabol), de mindig
elfolyik az idom mas lyukon. :S )

miert nem jo az, ha a php cgikent fut? miert jobb a mod_php?
ha cgi -s a php, akkor pedig elvileg a suexeccel tudod allitani, h ki
futtassa

udv,

Z

[Pallai Roland]

Post by Zoltan NAGY

Post by Sickboy
PHP hosting meg vagyon love minden fronton.
(Kene mar valami megoldas. Egyszer elkezdtem az apache(1.3) forrast
hackelni (process alapu perchild megoldas celjabol), de mindig
elfolyik az idom mas lyukon. :S )

miert nem jo az, ha a php cgikent fut? miert jobb a mod_php?
ha cgi -s a php, akkor pedig elvileg a suexeccel tudod allitani, h ki
futtassa

kb 4-8x lassabb sajat mereseim alapjan



--
dap

[Sickboy]

Post by Pallai Roland

Post by Zoltan NAGY

Post by Sickboy
PHP hosting meg vagyon love minden fronton.
(Kene mar valami megoldas. Egyszer elkezdtem az apache(1.3) forrast
hackelni (process alapu perchild megoldas celjabol), de mindig
elfolyik az idom mas lyukon. :S )

miert nem jo az, ha a php cgikent fut? miert jobb a mod_php?
ha cgi -s a php, akkor pedig elvileg a suexeccel tudod allitani, h ki
futtassa

kb 4-8x lassabb sajat mereseim alapjan

Plusz egyeb inkompatibilitasok is vannak a funkcionalitasban.
(Pl http auth, hogy csak egyet mondjak, akit erdekel, jarjon utana, hogy
mik meg.)

Az fcgi-s megoldas jol hangzik igy elso hallasra, meg fogom vizsgalni.
Viszont ez egyeb (funkcionalitas) szempontbol egy cgi-s php-nek felel meg,
vagy annal tobbet tud?

[Pallai Roland]

Post by Sickboy

Post by Pallai Roland

Post by Zoltan NAGY

Post by Sickboy
PHP hosting meg vagyon love minden fronton.
(Kene mar valami megoldas. Egyszer elkezdtem az apache(1.3) forrast
hackelni (process alapu perchild megoldas celjabol), de mindig
elfolyik az idom mas lyukon. :S )

miert nem jo az, ha a php cgikent fut? miert jobb a mod_php?
ha cgi -s a php, akkor pedig elvileg a suexeccel tudod allitani, h ki
futtassa

kb 4-8x lassabb sajat mereseim alapjan

Plusz egyeb inkompatibilitasok is vannak a funkcionalitasban.
(Pl http auth, hogy csak egyet mondjak, akit erdekel, jarjon utana, hogy
mik meg.)
Az fcgi-s megoldas jol hangzik igy elso hallasra, meg fogom vizsgalni.
Viszont ez egyeb (funkcionalitas) szempontbol egy cgi-s php-nek felel meg,
vagy annal tobbet tud?

ugy viselkedik mint egy CGI-s php. en most migralgatok vagy 500 szajtot
mod_php alol fcgi php -re, gyakorlatilag problemamentes az atallas,
nehany ritkan hasznalt kornyezeti valtozo amit CGI-kent mas neven lehet
elerni, de egy s/// ezt megoldja, aztan a modositott kod tobbnyire mar
hordozhato a mod_php es a php-cgi kozott, tehat visszafele mar
kompatibilis. persze ez csak tapasztalat, nem vagyok nagy php koder.

egyebkent szerintem nem erdemes hasznalni az extra ficsoroket amit az
apache+mod_php ad mert azt masik webszerverrel mar jellemzoen szinten
nem tudja.


--
dap

[Szabó Dénes]

Szia!

Post by Pallai Roland
ugy viselkedik mint egy CGI-s php. en most migralgatok vagy 500
szajtot mod_php alol fcgi php -re, gyakorlatilag problemamentes az
atallas, nehany ritkan hasznalt kornyezeti valtozo amit CGI-kent mas
neven lehet elerni, de egy s/// ezt megoldja, aztan a modositott kod
tobbnyire mar hordozhato a mod_php es a php-cgi kozott, tehat
visszafele mar kompatibilis. persze ez csak tapasztalat, nem vagyok
nagy php koder.

Zend/ioncube/phpaccelerator/ stb megy vele?

[Pallai Roland]

Post by Szabó Dénes

Post by Pallai Roland
ugy viselkedik mint egy CGI-s php. en most migralgatok vagy 500
szajtot mod_php alol fcgi php -re, gyakorlatilag problemamentes az
atallas, nehany ritkan hasznalt kornyezeti valtozo amit CGI-kent mas
neven lehet elerni, de egy s/// ezt megoldja, aztan a modositott kod
tobbnyire mar hordozhato a mod_php es a php-cgi kozott, tehat
visszafele mar kompatibilis. persze ez csak tapasztalat, nem vagyok
nagy php koder.

Zend/ioncube/phpaccelerator/ stb megy vele?

a Zend -et hasznalom es elvileg minden mas is megy, ezen a szinten
nincs kulonbseg a mod_php es php-fcgi kozt


--
dap

[Fagyal Csongor]

E,

Post by Pallai Roland

Post by Szabó Dénes
Zend/ioncube/phpaccelerator/ stb megy vele?

a Zend -et hasznalom es elvileg minden mas is megy, ezen a szinten
nincs kulonbseg a mod_php es php-fcgi kozt

Én is nagy FCGI fanatiker vagyok :-) Sok nyűgje van, de idővel ráérez az
ember. Tök jó, hogy külön processzként (szerverként) lehet kezelni,
externalserver-ként akár load balance-olva is (több szerveren fut a FCGI
alkalmazás, a front webszerver meg arbitrál, hogy melyik request-et
melyik back-nek tolja).

Külön ajánlom a lighttpd-t a célra.

Ha valaki akar PUGS-ban FCGI modult írni, szóljon ám! ;-)

E,
- Cs.

[Szabó Dénes]

Szia!

Post by Pallai Roland

Post by Szabó Dénes
Zend/ioncube/phpaccelerator/ stb megy vele?

a Zend -et hasznalom es elvileg minden mas is megy, ezen a szinten
nincs kulonbseg a mod_php es php-fcgi kozt

Talaltam mod_fastcgi-t es mod_fcgid-t. Ez utobbira azt irjak, kicsit
okosabb mint az elozo (bizonyos optimalizaciok).

Nade: a zend oldalon nem talaltam semmi infot arrol, h. az optimalizer
mukodik-e a php-cgi modjaban. Egy elejtett forum hozzaszolasban azt
irjak, h. elmeletileg mudokik, de nem az a fo mukodesi modja, igy ha
nem mukodik, akkor ijb.

Szal mi a helyzet? zend encoder-rel elkodolt php-t lehet fcgi-s
uzemmodban futtani?

Annak ellenere, h. keresek meg tovabb, es nezelodom a temaban, meg
tudnal dobni egy apache virt. szerver config reszlettel? Az a resz
erdekel, h. hogyan lehet juzerre lekorlatozni a php-t az adott virt.
hostra. Elore is koszonom!

[Pallai Roland]

Post by Szabó Dénes

Post by Pallai Roland

Post by Szabó Dénes
Zend/ioncube/phpaccelerator/ stb megy vele?

a Zend -et hasznalom es elvileg minden mas is megy, ezen a szinten
nincs kulonbseg a mod_php es php-fcgi kozt

Talaltam mod_fastcgi-t es mod_fcgid-t. Ez utobbira azt irjak, kicsit
okosabb mint az elozo (bizonyos optimalizaciok).

egyelore csak az elozot probaltam, de elvileg szabad a valasztas

Post by Szabó Dénes
Nade: a zend oldalon nem talaltam semmi infot arrol, h. az optimalizer
mukodik-e a php-cgi modjaban. Egy elejtett forum hozzaszolasban azt
irjak, h. elmeletileg mudokik, de nem az a fo mukodesi modja, igy ha
nem mukodik, akkor ijb.
Szal mi a helyzet? zend encoder-rel elkodolt php-t lehet fcgi-s
uzemmodban futtani?

cgi modban nemtom, de fastcgi modban mukodik (mint irtam: hasznalom),
tudja az elkodolt php-t is futtatni

Post by Szabó Dénes
Annak ellenere, h. keresek meg tovabb, es nezelodom a temaban, meg
tudnal dobni egy apache virt. szerver config reszlettel? Az a resz
erdekel, h. hogyan lehet juzerre lekorlatozni a php-t az adott virt.
hostra. Elore is koszonom!

na most nalam epp nem virtualhost -kent fut mert ebben az adott hosting
kornyezetben rewrite alapu tema van (jo bonyolult apache konfiggal), de
keresobe a 3 kulcsszoval kell h talalj mini/micro howto -kat, tryit


--
dap

[Fagyal Csongor]

E,

Post by Pallai Roland

Post by Zoltan NAGY
miert nem jo az, ha a php cgikent fut? miert jobb a mod_php?
ha cgi -s a php, akkor pedig elvileg a suexeccel tudod allitani, h ki
futtassa

kb 4-8x lassabb sajat mereseim alapjan

Ja. Akárcsak bármilyen CGI vs. perzisztens környezet. A startup overhead
miatt, ugye: a CGI-t execelni kell, az meg mi más ha nem fork... és hát
scriptek esetén ilyenkor egy fordítás is történi. Ha kicsi a scripted,
akkor az exec/fork rontja le a hatásfokot, ha nagy, akkor a compile time.

E,
- Cs.

[Pallai Roland]

Post by Sickboy
De rendben, maradjunk annyiban, hogy a kulso forrasbol kesz debkent
letoltott php az, amit ellenjavalltnak tartok.

hatnemtom', a dotdeb nagyon lelkiismeretesen csinalja, szerintem
abszolut hasznalhato, src-bol ujraforditva pedig tenyleg maximalisan
klappol adott rendszerre. nem latom ertelmet h magamnak forditsam

Post by Sickboy
[...]
Es ez az, amihez nincs rendes support apache-ban (es nem tudok semmi
masrol sem), mert nem tud mod_php-s siteokat kulon UID-kent futtatni.
(Lasd security-l ujra es ujra felmerulo tema.)
Az apache2 perchild (ami majd egyszer lesz) sajnos nem lesz majd egyszer
sem, mert thread-es, es sok "nepszeru" PHP extension (tehat amit sok php
coder a rendszer "reszenek" tart) nem thread-es (es a fejlesztok szerint
nem is lesz az).
PHP hosting meg vagyon love minden fronton.
(Kene mar valami megoldas. Egyszer elkezdtem az apache(1.3) forrast
hackelni (process alapu perchild megoldas celjabol), de mindig elfolyik az
idom mas lyukon. :S )

hat akkor tessek egy megoldas: apache2 (worker mpm v barmi) +
mod_fastcgi + php fastcgi tamogatassal forditva

a mod_fastcgi tud olyat h suexec modra egy virtualhost user/group
beallitasat figyelembe veve szul egy uj php-fastcgi instancet adott
uid/gid-re ami aztan kiszolgalja a virtualhost php-it sajat user alatt.
a sebesseg gyakorlatilag egyezik a mod_php-vel, az fcgi protokoll
overheadje minimalis, az fcgi modul pedig ugyesen banik a meglevo fcgi
peldanyokkal, ha valamire nincs szukseg szepen kill-ezi, kesobb ha megis
kell indit egy ujat, raadasul konnyen hekkelheto, egyszeru kod.
en a suexec tipusu uid/gid feloldas helyett csinaltam egy peccset h a
php script tulajdonosa alapjan valasszon php peldanyt a futtatashoz mint
pl a securecgi, ha esetleg nem per virtualhost alapon akarsz szeparalni
akkor ezt kirakhatom vhova.
egyebkent van par jo mini howto a temaban..


--
dap