Symfony & Composer sur serveur mutualisé 1&1

Version imprimable

14/02/2014, 00h26
Willy55

1 pièce(s) jointe(s)

Symfony & Composer sur serveur mutualisé 1&1

Bonjour, je sollicite votre aide car j'ai actuellement un soucis avec l'hébergement d'un projet en symfony2 sur mon serveur 1&1.

En effet j'upload symfony sans vendors et je les télécharge a l'aide de composer jusque la pas de soucis, mais lorsque je veux faire un composer update alors la systématiquement j'ai un "out of memory" de ce type :

http://img15.hostingpics.net/pics/484883erreur.png

J'ai cherché et trouvé qu'il s'agissait de la limite php trop faible pour l’exécution du script, j'ai donc appelé 1&1 qui m'ont en effet signalé que je ne disposait que de 32Mo de mémoire php, ce qui est faible pour symfony, j'ai changé de pack et je suis maintenant a 128 Mo de mémoire (comme en local ou sa tourne parfaitement) et j'ai toujours la même erreur au même endroit avec la même valeur de out of memory alors que j'ai 4 fois plus de mémoire ?

Je ne comprend pas...

PS : j'ai déjà essayé les différentes techniques avec le php.ini ça ne fonctionne pas.
14/02/2014, 00h41
dukoid

avec 1&1 faut se méfier. (bande d'incompétent lamentable)
tu as bien la preuve que tu as les 128mo ?
14/02/2014, 02h25
Tsilefy

Le message d'erreur dit que tu n'appelles peut-être pas composer avec la bonne version de PHP: il faut utiliser php-cli, or ta capture d'écran montre : "content-type=text/html".
Vérifie que tu utilises bien la bonne version (php -v) et surtout vérifie que la version que tu utilise a la bonne quantité de mémoire allouée (php -i | grep "memory_limit"). Les réglages ne sont pas les mêmes selon que tu utilises cgi ou cli.
14/02/2014, 16h55
Willy55

Merci, pour vos réponses, j'avoue que je n'ai jamais eu a me plaindre de 1&1 jusqu’à aujourd'hui avec symfony2 je m'en sors pas...

J'ai testé php -i | grep "memory_limit" qui m'affiche bien 120M.

Pour ce qui est de php-cli je ne connaissais même pas la différence, j'ai cherché partout mais il semblerait que c'est mort, c'est cgi point barre chez 1&1, j'ai cru comprendre que chez ovh ils utilisaient un suffixe bizarre pour avoir cli comme php.TEST.5 mais je ne trouve pas ça chez 1&1 et sur tous les sites que j'ai trouvé c'est dit que les serveur linux chez 1&1 utilise cgi...

Du coup je ne sais plus quoi faire... j'ai pris une offre plus élevée pour avoir plus de mémoire mais apparemment ça ne résoud pas le problème, je ne peux donc pas faire un simple composer update ? c'est quand même incroyable de galérer comme ça pour un simple symfony...

Si quelqu'un peut m'aider...

PS : évitez les "change d'hébergeur" svp, car malheureusement je n'ai pas vraiment le temps de faire cette démarche maintenant...

pourtant tu n'es pas le seul à avoir ce problème de mémoire sur 1&1 et pas seulement avec Symfony
http://www.lecoindunet.com/fatal-err...upal-et-11-429

en connaissance de cause , évitez à tout prix 1&1.

peut être ?
Code:

1 2 3 4 Il y a une solution (qui ne fonctionne pas toujours) mais qui marche dans certains cas donc à essayer, c'est de créer un fichier "php.ini" et de l'uploader à la racine de votre blog mais également dans le répertoire d'exécution du script (par exemple wp-admin pour les scripts de l'interface d'admin), ce fichier contiendra la ligne suivante: memory_limit=60M
bon qui peut l'aider ?

14/02/2014, 22h50
Tsilefy

La première chose que composer fait quand on le lance est d'augmenter memory_limit à 512M donc s'ils figent réellement la limite à 120, ton problème s'explique. Est-ce qu'ils désactivent la fonction ini_set() ?
14/02/2014, 22h55
Tsilefy

Comme alternative, pour certains clients qui n'ont pas un accès console, j'utilise composer chez moi et je synchronise ensuite les fichiers sur leur site. C'est plus long et plus embêtant, mais ça marche.
15/02/2014, 06h24
Willy55

Non dukoid, j'ai déjà essayé la technique du php.ini ça ne fonctionne pas, mais j'ai bel et bien 128 Mo de mémoire apparemment...

Ce qui me chagrine c'est ce php-cli parce qu'effectivement a chaque fois que j’exécute une commande ça me préviens d'utiliser cli mais bon...

Composer monte la limite a 512 ? Même dans ce cas je ne vois pas la gêne il n'a pas besoin de 512, 128 est largement suffisant pour l’exécution de composer, il y a des gens qui arrive a faire tourner symfony sur du mutualisé quand même et il sont quand même limité a ce niveau. Et puis ça ne correspond pas vraiment a mon erreur affichée...

En solution de dernier recours effectivement, j'ai uploadé tous mes fichiers en ftp et oui la ça fonctionne... mais c'est vraiment dégueulasse, d'autant que pour parfaire le chef d'oeuvre la commande pour update la base de donnée échoue aussi donc je suis obligé d'exporter la locale et d'aller l'importer directement dans ma bdd 1&1... Du dev de bricoleur...

Merci pour votre aide.
16/02/2014, 00h09
Tsilefy

Est-ce que tu te sers de la dernière version de composer?
Peux-tu poster ton composer.json ici?

Oui je pense que j'utilise la dernière version puisque c'est celle que j'ai téléchargée a l'aide d'un curl en local avant de la passer sur le serveur.

Le composer.json :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
{
	"name" : "symfony/framework-standard-edition",
	"license" : "MIT",
	"type" : "project",
	"description" : "The \"Symfony Standard Edition\" distribution",
	"autoload" : {
		"psr-0" : {
			"" : "src/"
		}
	},
	"require" : {
		"php" : ">=5.3.3",
		"symfony/symfony" : "~2.4",
		"doctrine/orm" : "~2.2,>=2.2.3",
		"doctrine/doctrine-bundle" : "~1.2",
		"twig/extensions" : "~1.0",
		"symfony/assetic-bundle" : "~2.3",
		"symfony/swiftmailer-bundle" : "~2.3",
		"symfony/monolog-bundle" : "~2.4",
		"sensio/distribution-bundle" : "~2.3",
		"sensio/framework-extra-bundle" : "~3.0",
		"sensio/generator-bundle" : "~2.3",
		"incenteev/composer-parameter-handler" : "~2.0",
		"friendsofsymfony/user-bundle" : "~2.0@dev"
	},
	"scripts" : {
		"post-install-cmd" : [
			"Incenteev\\ParameterHandler\\ScriptHandler::buildParameters",
			"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
			"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
			"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
			"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile"
		],
		"post-update-cmd" : [
			"Incenteev\\ParameterHandler\\ScriptHandler::buildParameters",
			"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
			"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
			"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
			"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile"
		]
	},
	"config" : {
		"bin-dir" : "bin"
	},
	"extra" : {
		"symfony-app-dir" : "app",
		"symfony-web-dir" : "web",
		"incenteev-parameters" : {
			"file" : "app/config/parameters.yml"
		},
		"branch-alias" : {
			"dev-master" : "2.4-dev"
		}
	}
}

17/02/2014, 22h21
Tsilefy

Je ne vois pas ce qui pourrait clocher, c'est le composer.json standard, à part FOSUserbundle. Peux-tu l'enlever, installer symfony, puis le rajouter et faire un update? Sinon, en dernier recours il reste l'option d'installation n°2 du manuel: tu uploads symfony manuellement sans les vendors, puis tu lances composer install, qui va installer les vendors et exécuter les scripts pre/post update. Et si ça ne marche pas ... :-(
17/02/2014, 22h52
arnooo999
As tu essayé
Code:

1 2 php5.4 composer.phar install --prefer-dist
22/02/2014, 19h47
Willy55

Désolé pour l'attente je n'ai pas eu l'occasion de répondre avant,

Pour le composer.phar install il n'y jamais eu de soucis, d'ailleurs pour être sur que ça ne venait pas de mes bundles personnel j'ai carrément essayé avec un symfony vierge sans vendor, le composer.phar install passe sans soucis mais au moindre update "CRAC" out of memory.

Finalement j'utilise la technique de copier le dossier vendor a la main, c'est chiant mais au moins ça marche !

Je retiens :

- ne plus jamais essayer de faire du symfony sur un serveur mutualisé
- le mutualisé c'est sympa 5 minutes, mais dès que j'en ai l'occasion je passe en dédié et si possible loin de 1&1 !

Merci pour votre aide a tous !