вторник, 10 ноября 2015 г.

БД обжирается памяти? Ребутаем по таймеру

Вчера у меня начались курсы по тестированию. В доп материалах есть отсылка на сам сайт Testbase — так я и получила баг-репорт от студента, сайт упал. База отвалилась.

Написала разработчику и в итоге поставили костылик:

Разработчик: Запустил, поставил перезапуск каждый день на 3:55.
Но я не настолько админ, чтобы понять чего там не хватает )
Разработчик: Там, судя по логам, кончается память.
Разработчик: sql-сервер наверное что-то кеширует.
Разработчик: Проще всего ребутать, потому что настраивать опухнешь там

Что в этой истории забавного — пару месяцев назад я услышала ровно о таком же хотфиксе от знакомого со своим небольшим сайтом. Та же проблема, но нагрузка побольше, поэтому сайт падал чаще. Покопались, покопались, обнаружили, что проще всего лечить ребутом. Поставили на таймер каждую ночь рестартить = проблема решена! Smile :)

В принципе, это действительно лучше, чем тратить кучу времени на настройку, администрирование и докрутку. Иногда проще обойти баг, чем его фиксить =)

16 комментариев:

  1. О_О
    Помнится, Спольски когда то писал, что конечно же, есть эффективность, целесообразность, но есть уже и факторы гигиены. Ну вроде как в 2015 году не использовать VCS - все равно что лезть в рот немытыми руками.

    Ощущение. что ребутать по таймеру из за утечки, это уже не эффективно, а негигиенично.

    ОтветитьУдалить
    Ответы
    1. Что предложите? Тратить человеко-дни разработчика, чтобы искать корень зла? :)

      Удалить
    2. Да. Судя по описанному контексту (простой проект, не highload, не на 1 день) - именно так.

      "Ради этого немытого яблока мне идти до колодца?"

      Удалить
    3. Спрошу потом у знакомого, дошел ли он до колодца :)
      И зачем мыть яблоко, если его не есть, а просто нести надо? Чем плох ребут, система разваливается?

      Удалить
    4. Костыль хорош, пока мы лечимся. Пока мы ищем проблему - ребут спасает сайт. Но по тексту я понял, что это постоянное решение.

      Удалить
    5. Да, если я не планирую съесть яблоко, я пока не буду его мыть.
      Если проблем ребут не начнет приносить, то пусть остается

      Удалить
    6. %)
      Что там у нас с метафорой? Есть яблоко - заниматься разработкой сайта дальше.

      Я не представляю себе, как он может не приносить проблем. Как минимум он маскирует проблемы и самое главное "я работаю на проекте с программистами, которые чинят лики ребутом по крону, аааа!!!"

      Удалить
    7. 1. Я пока не планирую "разрабатывать" сайт, вся нужная фнукциональность у меня уже есть.
      2. Если его разрабатывать и всплывут проблемы — тогда и чинить.

      Насчет "ааааа" — ну да, ппц какое "аааааа", разработчик предпочел заняться реальной работой, реальными багами на проекте, за который получает деньги, а не помочь мне бесплатно копаться и чинить баг, ни на что не влияющий. Аааааа, ооооооо, как так можно жить, когда ЕСТЬ БАГИ! Пока все не поправим, не быть покою!!!

      И пока из нашего диалога весь смысл "зачем чинить" — "ну как же, баг же есть", это как то больше на начинающего тестировщика смахивает. "Я ВВЕЛ ДРОБНОЕ ЧИСЛО В ПОЛЕ С КОЛИЧЕСТВОМ СТРОК И СИСТЕМА НЕ ВЫДАЛА ОШИБКУ! ВСЕ, Я ЕЙ БОЛЬШЕ НЕ ВЕРЮ Я УШЕЛ ВЫ ПОТЕРЯЛИ ПОЛЬЗОВАТЕЛЯ! СРОЧНО ЧИНИТЕ БАГ!".

      Удалить
    8. У меня не было столько контекста, Ольга ;) Про деньги и основную работу.

      А еще я говорил, если формализовать, о приоритизации баг по т.н. "гигиеническому фактору". То, с чем жить просто стыдно в приличном обществе. А не о просто "есть бага".

      Удалить
    9. Ну так я же написала, что проблема возникла на Testbase :)
      А это или из моего кармана, или вообще бесплатно — так что лень разработчика меня вообще не смущает. Мне самой, например, лень покопаться в этом и поизучать, проблемы то нет. Чего и его дергать?

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

      Удалить
    10. Согласна с Wolonter -- если лечить симптом, а не причину, это может привести к нехорошим последствиям. В данном примере, если нагрузка увеличится, то рестартовать может понадобиться не раз в сутки, а раз в час. Что уже может сказаться на пользователях. Да, иногда есть проблемы, которые сложно решить здесь и сейчас, и временно можно подпереть костылем. Но задача команды разработки в том, чтобы эти костыли не были забыты, и не висели грузом технического долга вечно.

      Удалить
    11. Ключевое слово "ЕСЛИ".
      Это как делать высоконагруженный сервис, потратив кучу времени и денег НА СЛУЧАЙ, что туда будут ходить такие же толпы, как на амазон.

      "Команда разработки", "задачи технического долга" — вы мыслите шаблоном работы, нормальной работы. А бывают еще фриланс проекты или свои собственные, как Testbase, например. Откуда там команда разработки? Откуда там вообще задачи. Я вам по секрету скажу, что у нас и, о ужас, багтрекера то небыло, без него сбацали сайт. Вот кошмар то, как можно работать без стандартных правил =(

      Удалить
    12. Опыт подсказывает, что костыли имеют обыкновение не быть независимыми и разваливаться в один прекрасный момент все вместе. И часто это бывает ответственный момент. Например, один чувак забил на то, что течет память,а второй не подумал, и увеличил расход памяти. В результате, никто конкретно в проблеме не виноват, но продукт разломан.
      Ну да, я мыслю шаблоном нормальной работы. Я стараюсь и какие-то вещи "для себя" делать не халтуря. Но вообще,позиция "мне за это не платят деньги напрямую, поэтому я буду делать плохо" мне не близка, но имеет право на существование.

      Удалить
    13. Да да, разумеется, у меня позиция "мне за это не платят деньги, поэтому я буду делать плохо", ок. У продукта нарисовалось несколько разработчиков и он внезапно стал сломан :( Бедные юзеры, не переживайте, мы скоро все починим! И будем равняться на "нормальные работы", в которых никогда-никогда-никогда не ставят костылей. Ну, по крайней мере на словах...

      Удалить
  2. В принципе, это действительно лучше, чем тратить кучу времени на настройку, администрирование и докрутку. Иногда проще обойти баг, чем его фиксить =)

    Регулярно слышу это от разработчиков :) Мол это не важно.
    Я всегда отвечаю на это, зачем получать премию, проще ее обойти и получать только зарплату :)

    ОтветитьУдалить
    Ответы
    1. Задача тестировщика — обосновать баг :)
      Доказать, что его стоит исправлять!

      Но в данном случае — не стоит, потому что это не основная работа и не проект, который мы отдаем Заказчикам :) А то, что че-то там внутри Testbase ребутается — пользователи даже не заметят

      Удалить