| Summary: | Scaling doesn't work properly - PHP | ||
|---|---|---|---|
| Product: | OpenShift Online | Reporter: | info |
| Component: | Image | Assignee: | Paul Morie <pmorie> |
| Status: | CLOSED NOTABUG | QA Contact: | libra bugs <libra-bugs> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 2.x | CC: | dmcphers, info, jhadvig, jhonce, vvitek |
| Target Milestone: | --- | Keywords: | Reopened, SupportQuestion, UpcomingRelease |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-03-03 17:30:38 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
info
2013-12-03 15:55:11 UTC
If we could get some additional info it would help to diagnose the issue with your app. Would you provide: 1. Your app's name 2. Your openshift domain 3. The email address associated w/ the account Thanks Additionally, what is your app trying to do? Are there any per-connection operations that could explain the performance issues you're seeing? app name is rain which you can find at rain-dogshouse.rhcloud.com and email address is info [a t ] pempo.it The app is just a simple scalable Wordpress (scalable) installation which I used to test the platform and gears'capacity. The code is probably not perfect but the scaling behaviour i'm showing is probably not related to that. And yes, I used the explicit database address and port. I can send you the full logs pointing out the times where I caused the bug. Hi, so the problem really is that for now our cartridges are not "scaleable", cause when your app is scaled-up, new gears are added to your application and HAproxy decides which of the gear will serve incoming request and action are made in the application(e.g. uploaded static files). But those changes aren't synced with other gear, so after that gear is scaled-down some of the gears are destroyed and you lose those changes(uploaded static files, etc.) But if you want there is a workaround for the wordpress: https://www.openshift.com/blogs/how-to-automatically-scale-wordpress-on-openshift So I suggest to close this one as WONTFIX Hello Jakub, I do know that uploaded static files which do not go into the data dir will not be synced if they are on secondary gears. In this case I can run the very minimal risk as uploads can made happen on the primary gear and also loosing some static uploaded files on a replicated gear does not imply the behaviour I described above. This has nothing to do with what happens in my case, which is that if I manually set the gears to 2 minimum no content of the primary gear gets copied on the second, to make it really short. I need to set it manually because the resources are too low to handle more than a few cunc connections, rather than 15 which is when the haproxy scales automatically. Hi- What content on the primary gear are you expecting to be synced to the second gear? P > "Unable to allocate memory for pool" error points to the APC memory failure, meaning that the PHP application consumes too much gear memory. This might be related to (or duplicate of) bug 1001400. Trello cards for APC: 1. Disable/Edit APC settings manually: https://trello.com/c/1VcpoZTf 2. Disable APC automatically via DEVELOPMENT MODE: https://trello.com/c/lbjDOA6S Closing as upstream based on the trello cards referenced. I do not understand why it's closed. This is not related to the APC issue, which is only why the gear doesn't scale automatically. The problem is that if I manually set the gears to minimum 2 the content is not replicated on the second gear. When you ask what content should be synced, well, everything, otherwise how is the app supposed to work? The content that is synced to the new gears is the deployments and dependencies directories. Are you expecting something other than that to be synced? no. For example, try to connect to pempo.it now. If you connect to the main gear you see a typical wp installation, on the second gear you get the default openshift index.php It doesn't look like rain-doghouse has php scaled up at the moment. Would you scale up to 2 so we can take a look at the logs? Thanks, Paul I have set minimum 2 maximum all available at rain-dogshouse I did the same for pempo.it which is another test project they both hand the correct installation if the connection is routed to the main gear, and the standard openshift php installation files if on the second gear, which in the rain-dogshouse case is: gear-52fdf88b500446c4a5000249-dogshouse I suppose this bug cannot be fixed? How comes as it is very severe as an issue? It looks like you're editing index.php in app-root/runtime/repo directly. In order to get your changes deployed correctly into the app (ie, so that auto-scaling will correctly scale up the new gear with your application's code), you need to git clone your application's repo and deploy your changes using git push. See 'How do I use OpenShift Online?' in the following link: https://www.openshift.com/products/online Another getting started guide: https://www.openshift.com/get-started |