When the memcache infrastructure is updated, patched, or auto-scaled, its network address gets updated dynamically, and your running Drupal 7 application does not natively look up the address. During such period, such Drupal 7 applications may experience temporary slowness or brief periods of 5xx errors. This is an existing issue with Drupal 7 and memcache.
Workaround:
Add the following configuration to your settings.php file:
$conf['memcache_persistent'] = FALSE;This ensures that the application handles connection resets gracefully. However, this may increase the baseline response time by typically 1-2 seconds. Nevertheless, Acquia recommends that you add this property as it provides greater stability during platform maintenance. In addition, having this property in the settings.php file reduces impact during maintenances that result in a memcache clear. By implementing the provided workaround, you can mitigate the impact.
If the definition of a VIEW contains the database name in its defining query, you cannot copy or import databases.
Workaround: To remove any instances of the database name from the VIEW, see the ALTER VIEW Statement.
You cannot have more than 5000 processes for Drupal, SSHD, scheduled tasks, and Cloud Hooks. If you exceed the process limit, the system restarts the service. This interrupts running requests and results in 50x errors for Drupal.
Web requests that take longer than 10 minutes might be interrupted by routine platform maintenance activities.
The Cloud Platform user interface may occasionally display two daily backup tasks for the same day, indicating the backups taken at different times of the day.
Scheduled jobs or cron jobs in Cloud Platform must not use hardcoded host names in log paths. However, if you use /shared/logs as the directory, you can use hardcoded paths.
When you create scheduled jobs in Cloud Platform, your cron task duration must not be more than 3 hours. If your cron job lasts longer than that, it terminates.
Killed or Exit status 137.Currently, you cannot increase the PHP file upload size values beyond the limits available in the Cloud Platform user interface. The maximum size for Cloud Platform is 1024 MB.
For FedRAMP customers, Cloud Platform uses individual mcrouter instances on each pod. This obscures information such as cache hits or misses and might misreport metrics on each report. Therefore, the memcache_admin module does not correctly report the status of memcache instances. Cumulative statistics, available memory, and evictions are reported as zero. In addition, other statistics might be misreported.
Workaround: To gather memcache statistics, run the following command in an SSH session:
The database copy, backup, and restore operations are updated to maintain compatibility between MySQL 5.7 and MySQL 8. This update modifies any data in your database from utf8mb4_0900_ai_ci to utf8mb4_general_ci during these operations.
If your Cloud Platform application uses a Custom Varnish Configuration (cVCL) file to restrict access based on IP addresses, you might experience issues with the module.
Code deployment in Cloud Platform can take a maximum of 1 hour. Environments on Cloud Platform may intermittently experience code deployment times taking more than 5 minutes. Ensure that you close your SSH session before starting your code deployment. If you are in an SSH session and start code deployment, the process might fail.
Git repositories in Cloud Platform must not exceed 2 GB. If your repository size exceeds this limit, code deployment tasks might fail without displaying any public logs. In such a case, you must verify that the combined size of all files in the specified Git branch or tag is less than 2 GB. For more information, visit Disk Storage.
Before the platform database upgrade to MySQL 8.0, Acquia performs a series of automated pre-upgrade checks. For information about all the pre-check error descriptions, visit AWS Aurora MySQL.
APCu is disabled on the command line interface. For instructions on how to enable it, refer to Enabling APCu and ChainedFastBackend to speed up long Drush operations.
Acquia deployed New Relic PHP agent version 12.11.0.40 to all Cloud Platform environments. This version supports PHP Fibers, which Drupal 11.3 and later versions use for parallel task execution.
If your site uses Drupal 11.3 or later, the response time line in the Web transactions time chart in New Relic APM appears lower than the sum of the PHP, Database, Memcache, and External component bars. This behavior is expected and does not indicate data loss or a system error. The lower line reflects PHP Fibers running tasks concurrently, which reduces total wall-clock response time compared to cumulative execution time.
For detailed information about chart behavior and APM data interpretation, refer to Understanding New Relic APM chart behavior with PHP Fibers in Drupal 11.3 and later.
You must not follow previous workarounds, such as delaying the Drupal 11.3 upgrade or deactivating New Relic.
Daily database backups on Cloud Platform might not trigger at the scheduled time. Database backups can run up to 12 hours later than the configured schedule. For example, a backup scheduled at 08:04 UTC might run at 20:00 UTC. This issue can occur across all environment types, such as Development, Staging, and Production.
The daily backup completes successfully, but at a different time than expected. This issue affects workflows that depend on backups that run in a specific time window, such as coordinated database restores or pre-deployment verification.
Workaround: To create a backup at a specific time, use the Cloud Platform user interface to create an on-demand backup.
When users submit an SSH public key, Cloud Platform displays the following error message:
Error: Key already in useThe submitted SSH public key is already associated with another Cloud Platform user account. Acquia enforces key uniqueness across user accounts to maintain precise attribution and auditability of all SSH operations.
Workaround: Generate and attach a unique SSH key pair to the account.
Cloud Platform does not capture watchdog logs, which the Drupal Logging API generates, in all cases. For tasks executed through Cloud Hooks or Scheduled Jobs, the system captures these logs as drupal-watchdog logs and makes them available to stream and forward logs. However, the system does not capture these logs for download through Cloud UI, Cloud API, or the Acquia SIEM system. The system does not capture watchdog logs for tasks executed through SSH.
Workaround: Configure tasks to execute through HTTP requests with the HTTP Drush Wrapper module. HTTP requests expire after 10 minutes.
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Code deployment in Cloud Platform can take a maximum of 1 hour. Environments on Cloud Platform may intermittently experience code deployment times taking more than 5 minutes. Ensure that you close your SSH session before starting your code deployment. If you are in an SSH session and start code deployment, the process might fail.
Git repositories in Cloud Platform must not exceed 2 GB. If your repository size exceeds this limit, code deployment tasks might fail without displaying any public logs. In such a case, you must verify that the combined size of all files in the specified Git branch or tag is less than 2 GB. For more information, visit Disk Storage.
Before the platform database upgrade to MySQL 8.0, Acquia performs a series of automated pre-upgrade checks. For information about all the pre-check error descriptions, visit AWS Aurora MySQL.
APCu is disabled on the command line interface. For instructions on how to enable it, refer to Enabling APCu and ChainedFastBackend to speed up long Drush operations.
Acquia deployed New Relic PHP agent version 12.11.0.40 to all Cloud Platform environments. This version supports PHP Fibers, which Drupal 11.3 and later versions use for parallel task execution.
If your site uses Drupal 11.3 or later, the response time line in the Web transactions time chart in New Relic APM appears lower than the sum of the PHP, Database, Memcache, and External component bars. This behavior is expected and does not indicate data loss or a system error. The lower line reflects PHP Fibers running tasks concurrently, which reduces total wall-clock response time compared to cumulative execution time.
For detailed information about chart behavior and APM data interpretation, refer to Understanding New Relic APM chart behavior with PHP Fibers in Drupal 11.3 and later.
You must not follow previous workarounds, such as delaying the Drupal 11.3 upgrade or deactivating New Relic.
Daily database backups on Cloud Platform might not trigger at the scheduled time. Database backups can run up to 12 hours later than the configured schedule. For example, a backup scheduled at 08:04 UTC might run at 20:00 UTC. This issue can occur across all environment types, such as Development, Staging, and Production.
The daily backup completes successfully, but at a different time than expected. This issue affects workflows that depend on backups that run in a specific time window, such as coordinated database restores or pre-deployment verification.
Workaround: To create a backup at a specific time, use the Cloud Platform user interface to create an on-demand backup.
When users submit an SSH public key, Cloud Platform displays the following error message:
Error: Key already in useThe submitted SSH public key is already associated with another Cloud Platform user account. Acquia enforces key uniqueness across user accounts to maintain precise attribution and auditability of all SSH operations.
Workaround: Generate and attach a unique SSH key pair to the account.
Cloud Platform does not capture watchdog logs, which the Drupal Logging API generates, in all cases. For tasks executed through Cloud Hooks or Scheduled Jobs, the system captures these logs as drupal-watchdog logs and makes them available to stream and forward logs. However, the system does not capture these logs for download through Cloud UI, Cloud API, or the Acquia SIEM system. The system does not capture watchdog logs for tasks executed through SSH.
Workaround: Configure tasks to execute through HTTP requests with the HTTP Drush Wrapper module. HTTP requests expire after 10 minutes.
If this content did not answer your questions, try searching or contacting our support team for further assistance.