Тайм-аут Google App Engine: истекло время ожидания операции хранилища данных или данные были временно недоступны - PullRequest
Новая
       16

Тайм-аут Google App Engine: истекло время ожидания операции хранилища данных или данные были временно недоступны

11 голосов
/ 20 января 2011

Это частое исключение, которое я получаю в журнале своего приложения ежедневно, обычно 5/6 раз в день с трафиком 1K посещений в день: 

db error trying to store stats
Traceback (most recent call last):
  File "/base/data/home/apps/stackprinter/1b.347728306076327132/app/utility/worker.py", line 36, in deferred_store_print_statistics
    dbcounter.increment()
  File "/base/data/home/apps/stackprinter/1b.347728306076327132/app/db/counter.py", line 28, in increment
    db.run_in_transaction(txn)
  File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 1981, in RunInTransaction
    DEFAULT_TRANSACTION_RETRIES, function, *args, **kwargs)
  File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 2067, in RunInTransactionCustomRetries
    ok, result = _DoOneTry(new_connection, function, args, kwargs)
  File "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py", line 2105, in _DoOneTry
    if new_connection.commit():
  File "/base/python_runtime/python_lib/versions/1/google/appengine/datastore/datastore_rpc.py", line 1585, in commit
    return rpc.get_result()
  File "/base/python_runtime/python_lib/versions/1/google/appengine/api/apiproxy_stub_map.py", line 530, in get_result
    return self.__get_result_hook(self)
  File "/base/python_runtime/python_lib/versions/1/google/appengine/datastore/datastore_rpc.py", line 1613, in __commit_hook
    raise _ToDatastoreError(err)
Timeout: The datastore operation timed out, or the data was temporarily unavailable.

Функция, вызывающая вышеупомянутое исключение, следующая: 

def store_printed_question(question_id, service, title):
    def _store_TX():
        entity = Question.get_by_key_name(key_names = '%s_%s' % \
                                         (question_id, service ) )
        if entity:
            entity.counter = entity.counter + 1                
            entity.put()
        else:
            Question(key_name = '%s_%s' % (question_id, service ),\ 
                          question_id ,\
                          service,\ 
                          title,\ 
                          counter = 1).put()
    db.run_in_transaction(_store_TX)

По сути, функция store_printed_question проверяет, был ли заданный вопрос напечатан ранее, увеличивая в этом случае соответствующий счетчик в одной транзакции.
Эта функция добавляется WebHandler к отложенному работнику, использующему предопределенную очередь default , которая, как вы, возможно, знаете, имеет пропускную способность из пяти задач количество вызовов в секунду.

На объекте с шестью атрибутами (двумя индексами) я подумал, что использование транзакций , регулируемых отложенным пределом частоты задач, позволит мне избежать тайм-аутов хранилища данных, но, просматривая журнал, эта ошибка по-прежнему показывает ежедневно.

Этот счетчик, который я храню, не так важен, поэтому я не беспокоюсь о получении этих таймаутов; в любом случае мне любопытно, почему Google App Engine не может правильно справиться с этой задачей даже с низкой скоростью, например, 5 задач в секунду, и если снижение скорости может быть возможным решением.
счетчик на каждый вопрос, чтобы избежать тайм-аутов, будет для меня излишним.

EDIT:
Я установил ограничение скорости в 1 задание в секунду в очереди по умолчанию; Я все еще получаю ту же ошибку.

Ответы [ 2 ]

8 голосов
/ 03 августа 2012

Запрос может жить только 30 секунд.См. Мой ответ на этот вопрос , где приведен пример кода для разбивки запроса с помощью курсоров.

7 голосов
/ 20 января 2011

Вообще говоря, такой таймаут обычно происходит из-за конфликта записи .Если у вас запущена транзакция и вы одновременно записываете кучу материала в одну и ту же группу сущностей, вы сталкиваетесь с проблемами конкуренции при записи (побочный эффект оптимистического параллелизма ).В большинстве случаев, если вы делаете группу сущностей меньше, это, как правило, минимизирует эту проблему.

В вашем конкретном случае, основываясь на приведенном выше коде, это, скорее всего, потому, что вы должны использовать защищенный счетчик , чтобы избежать суммирования сериализованных записей.

Еще одна гораздо менее вероятная возможность (упоминаемая здесь только для полноты), что планшет, на котором находятся ваши данные, перемещается .

...