Проблемы с непрерывным чтение файла из сетевой папки?
Здравствуйте. Даже не знаю в какую область отнести этот вопрос. У нас в организации есть программа которая в качестве хранилища информации использует исключительно файлы. У нее есть серверная часть которая ежесекундно ведет базу (фактически пишет информацию в файлы) и клиентские приложения которые эти файлы читают. Доступ к ним они получают через сетевые папки, то есть у пользователя подключается сетевой диск, программа при запуске открывать файлы базы на этом диске на чтение и во время работы просто читает новые строки из файлов (открываются файлы один раз при запуске программы и соответственно закрываются при ее закрытии) На сколько хороша или плоха эта архитектура упустим.
Суть проблемы в том что в нашей организации стали появляться компьютеры где эта система дает сбой. Поясню. Сетевой диск доступен и через проводник все файлы доступны и открываются. При запуске программы она без проблем открывает файлы и получает информацию, а вот дальше происходит странное, она не видит, что файл дописывается, и соответственно не обновляет информацию.
Программа написана на делфи и использует системные ф-ции Windows API ReadFile из Kernel32.dll.
Немного инфы по проблемным компам:
1) У нас в организации больше 5 тысяч ПК разбросанных по всей стране, а ошибки возникают ну может на 3-5%.
2) Сами компы ничего не объединяет, это разное железо, разные билды ОС.
3) У нас есть партия из 50 моноблоков в одном крыле на 49 все работает, а на 50 нет, хотя один одинаковые, и даже ОС на них оем (по логике должна быть одинаковая).
Пробовали общаться с разработчиками, они утверждают, что проблема не в софте, а в системе, но мы уже сломали себе головы пытаясь понять в каком месте системы формируется такое странное поведение.
"они утверждают, что проблема не в софте, а в системе" - на основании чего они делают такое заявление? Пока причина проблемы не выяснена, оно не может быть истинным.
Я уточню сценарий.
1. Запускается сервер. Что-то пишет в клиентский файл (на той же машине, что и сервер).
2. Запускается клиент. Подсоединяется к клиентскому файлу через сетевой диск, читает данные.
3. Сервер каждую секунду ищет обновления. Если нашел - дозаписывает их в файл.
4. Что именно делает клиент? Каждую секунду пытается считать новую строку? Как именно определяется, что файл доступен, а клиент не видит новые данные? Возможна ли ситуация, когда новые данные пришли, клиент их не прочитал, и без выключения клиента можно открыть файл в блокноте и увидеть новые данные?
Oxoron: Да файл можно открыть в блокноте, пока клиент открыт и более того, если файл в этот момент открыть любым средством (тот же блокнот) то клиент мгновенно понимает, что новые данные появились и обрабатывает их, после чего все вновь останавливается.
Евгений Елчев: Размеры файлов для данных машин выделяются? Объемы записей?
В принципе, у Вас уже есть костыльное решение: написать скрипт, который будет раз в n минут открывать этот файл в блокноте, и тут же процесс блокнота закрывать (плюс закинуть скрипт в автозагрузку).
На сколько хороша или плоха эта архитектура упустим.
Какраз это упускать и не нужно.
Подобные выверты работают на ура пока имеем небольшое количество клиентов, с их ростом начинаем упираться во всякие ограничения как программные так и физические.
Пробовали общаться с разработчиками, они утверждают, что проблема не в софте, а в системе,
Моё мнение что проблема в софте, по описанию работы этого софта я вижу решения "на авось" и явно не вложена маштабируемость. Да и вообще использовать сетевую шару для нонстоп обмена данными - извращение.
Предложите разработчикам всё-же выполнить свою работу (если софт заказной) и переписать свой ласопед на работу с БД.
В общем софт явно делался из расчёта "здесь и сейчас решить задачу" и не думали о завтра.
Понимаете, я не против того что вы описали, но это все не сработает. У нас огромная организация и структура управления далека от идеала, где то там сидят несколько людей которые выделены чуть ли не в дочернее предприятие, они начинали проект хз в каком лохматом году и я подозреваю, что они не имели опыта написания сложного софта. Так вот у нас всем плевать на то как хорошо, что то работает, пока оно работает. Грубо говоря пока эта софтина не начнет падать без разбору хотя бы на 30% рабочих и это нельзя будет никак изменить настройкой рабочего места никто не пошевелится.
Вы будете продолжать бороться с мельницами, причём с каждым рабом этих мельниц будет больше.
Единственный адекватный выход это переписать ПО для работы в нынешних реалиях, лучше даже просить это сделать других разработчиков (у этих явно проблема, редко решаемая даже лохматастью годов :) ).
Пытайтесь донести этот факт до начальства, можете так и говорить "мы упёрлись в тех. возможности реализации, или пишем новое ПО или забудьте про новые раб. места", темболее что это будет собственно вполне правда.
Я знаю что они скажут и к сожалению не могу тут ничем помочь.
В что именно вы упёрлись с этим багом, я не знаю, к сожалению не знаком так глубоко с Windows API и его тонкостями работы. Но архитектурную проблема вижу и более чем уверен что если решите сейчас проблему то это явно не надолго :(
Евгений Елчев
> Грубо говоря пока эта софтина не начнет падать без разбору хотя бы на 30% рабочих
сделайте письменное предупреждение о том, что по вашему мнению скоро начнутся проблемы, и ваше видение их решения, и садитесь и "ждите" этих 30%, если по мнению начальства оно еще "работает". Я вижу что вы хотите выполнять свою работу, раз заранее беспокоитесь по отдельным жалобам, а начальство нет, вот поэтому выполните свою и подтвердите это на бумаге.
Сетевая шара - это doc-файлы кидать туда-сюда, и pdf-ки. Это не для работы с нормальной БД
Евгений Елчев мы это понимаем тут все, это всеобщая проблема менеджмента в большинстве отечественных компаний.
Но врятли чем-то поможем вам в ошибке изначального планирования архитектуры и твердолобым руководством.
Алексей POS_troi: Суть в том, что если косяк воспроизводиться всего на некоторых машинах его можно убрать вообще. Чем то же отличаются эти компьютеры от других. Если Абстрагироваться от программы и прочего , то что мы имеем в сухом остатке? Файл в шаре и функцию file.open или ее аналог (не знаком с этой либой) и открытый файл с флагом позволяющим другим приложениям менять этот файл.
Я так понимаю у этой функции есть некий механизм для проверки появилась новая инфа в файле или нет. И он по каким то причинам не знает об этом обновлении.
То есть знатоки Winapi возможно знают, что такого делает функция открытия файла, чего она потом не делает во время проверки обновлений.
Евгений Елчев убеждать в чем? я вам совет даю, изложите проблему в письменном виде, серьезно. Это помогает, когда начальник начинает снимать ответственность и прикидываться ребенком.
Понимаете, механизм этот плохо предназначен для интенсивных обновлений. Он тупо неотработан для интенсивных ситуаций.
Компьютеры могут много чем отличаться, дело в том, что в ОС достаточно много алгоритмов, которые стараются различать максимально похожие компьютеры, например, алгоритм генерации GUID. Очень много где генерируется различных значений, зависящих от каких-нибудь серийных номеров или текущего времени (в том числе, при сетевом взаимодействии). Такие баги в софте потому и называют "плавающими", что они х..н пойми когда воспроизводятся. Вопрос в том, критично ли отлавливать в конкретном сервисе подобные баги или нет и на них забивают.
Еще раз: все тут прекрасно понимают, что вы не сядете и не перепишете сами этот софт. Мы вам объясняем, что нужно проблему эскалировать наверх всеми силами.
Есть у меня клиент, уже 8 лет с ним работает.
В самом начале, когда он впервые мне позвонил, у него была сетка на 10МБит!, 1С7.7 в шареной папке и десять человек в ней работающие.
Пока у него было 7 человек, всё вроде как работало а нанял ещё троих и тут начались подвисания в базе, слёт индексов и ещё фиг пойми какая чертовщина.
Моё заявление о том что не плохо бы сеть на соточку сменить (благо помещение мелкое и всего один свитч) да и терминальный сервер надобно под 1С.
На что я получил ответ что есть спецы покруче меня и обещались всё сделать малой кровью и без этих ваших серверов и сеток, раньше же работало, просто подкрутить.
Я ушел и благополучно забыл про него.
~Через пол года он опять позвал меня, проблема та-же (только сетка уже сотка), а база как была в шаре так и лежит и людей уже ~20.
Оказывается что ему за пол года сменили почти всё юзерское железо (по принципу , тут бы проц поменять и т.п.), перетянули сеть и не хило так "1С программисты" выкачали денег за якобы оптимизацию.
Поставился ему в результате сервак терминальный, база так и осталась в файловом варианте (там у программёра какая-то проблема была с переносом в SQL, много дописано было), полтора года назад перешел на SQL 1С8. Сколько нынче работников там я не знаю даже, много филиалов мелких и к тех. проблемам старается подходить без эмоций и особой экономии.
Мораль истории такова - решать проблему высосанную из "оно-же раньше работало", как правило сулит финансовые/репутационные потери в неограниченных количествах.
Станислав Макаров: Я прекрасно понял ваш совет, но вы не понимаете всей серьезности ситуации. У Меня только до начальника нашего филиала 3 человека стоит, у тех еще не меньше и еще звено из целой организации где одно начальство сидит. У нас есть целая система по управлению задачами, инцидентами и проблемами. Где все зарегистрировано, все в курсе. Но если вы думаете, что это так просто убедить больше 100 человек, что они должны нанять еще 10 (потому изначальных разработчиков нельзя просто взять и заставить все переписывать, они поддержкой заняты), что бы они написали еще одну систему взамен той которая отлично работает, просто у некоторых людей есть проблемы и в ней архитектура говно, то вы очень сильно ошибаетесь. Первую версию внедряли около 7 лет, и до сих пор куча народу не знает, что с ней делать, это такая куча затрат, что если бы отдать мне деньги которые нужны на эту затею, я думаю мог бы просто никогда больше не работать, а может еще и мои дети.
Евгений Елчев: Вы, случайно, не в корпорации зла работаете (был подобный пост на Хабре)? Если серьезно, 3-5% машин от 5000 - это 200 штук. Проблема (как я понял) возникает регулярно, есть стабильно косячные машины. Итого у Вас воспроизводимый баг в ПО. Найдите способ обратиться к разработчикам. Аргумент "менять архитектуру" не используйте - вместо этого попросите добавить логирование в прогу. Логирование каждой строчки (возможно) поможет выявить багу и понять причины её возникновения.
Итого, вы должны убедить свое начальство, что в софте неизвестная хня, из-за которой не работают 200 компов. В идеале было устроить подобный баг начальнику, но, полагаю, Вы на это не пойдете. Для того, чтобы эта хня стала известной (и решаемой), нужно попросить отдел разработки "написать 10 строчек". 10, Карл! Не всю систему переделывать. Тут стоит заметить, что данный случай как входит в категорию "поддержка" системы, то есть, отдел разработки как раз и должен заниматься подобными ситуациями.
Oxoron: Понимаете в чем проблема ответа этого топика? Вы пытаетесь убедить меня, что мне нужно действовать в направлении разработчиков, а мне это не нужно. Этим занимаются другие люди, в частности и мой начальник. Мне конкретно хотелось как то решить эту проблему, если не получиться не беда, но я не думал что никто никогда не сталкивался с такой проблемой.
Тоже пытался работать с подпиской на эти функции, работает через ж. Проблема в сервере, который как я понял "не отправляет уведомление клиентам" и соответственно те не видят что обновление произошло. Иногда помогает переустановка оси на сервере, но временно, потом все равно перестает работать.
Тут суть в том что прога эта дико старая, хоть и развивается. Конкретно этот наш сервер работает уже больше 5 лет. И раньше вроде проблем не было. На сервере конечно ставятся обновления, может они виноваты, но почему 5% машин? почему тогда не все, не половина? Опять же по функциям, это же просто открытие файл на чтение, разве не клиент читает новые строки? Вообще по началу все грешили на некий кэш сетевых файлов на клинентских местах, но не так уж и много нашил о этом в интернете, но все что нашли отключили, проблема не решилась.
Евгений Елчев: есть подозрение, что это связано с разрывом соединения в какой то момент времени (потерей пакета), одно точно знаю, что иногда работает, иногда нет, в итоге в своем софте я отказался совсем от api и просто перепроверял размер и дату изменения файла.
Евгений Елчев: Точно! Потери пакетов! Столкнулся с подобным разик, когда в нашей транспортной проге начали отваливаться узлы. Клиенты начали отваливаться с ростом числа соединений и нагрузки. Проблема была в том, что отклик от сервера шел дольше разрешенного времени.
Железно помогали перезапуск клиентов\сервера и снижение максимального размера передаваемых файлов.
Повторять про программное обеспечение не буду, так как все точно и правильно написано, но проблему в любом случае надо решать, и здесь могу посоветовать сделать терминальный сервер с подключением к этой шаре, а клиентам раздать rdp-ярлыки. Можно целиком удаленку, можно через RemoteApp.
В такой конфигурации точка отказа сети будет только одна.
У нас есть такая модель подключения. Используется citrix, но проблема в том, что не всем она подходит. Потому, что некоторые клиенты еще и пишут в эту базу.
Эта проблема похоже в сетевом взаимодействии. Теряются пакеты в сети по пути следования и коннект зависает пока не передернуть - на сервере коннект отваливается по таймауту, а клиент не в курсе этих событий.
Как временное решение - переоткрывать файл если не было обновлений последнюю минуту.
Но по всей видимости, проблему можно решить проще написав под это дело свой сервер, который просто будет рассылать всем подключившимся клиентам изменения вносимые в файл. По всей видимости, изменения в код необходимо внести минимальные - вместо функции открытия файла подставить функцию открытия сокета, а чтение заменить чтением из сокета.
Средний
Простой
